Исторические дефекты безопасности популярного CMS PHP?
Я создаю CMS PHP, тот, что я надеюсь, будет использоваться общественностью. Безопасность является главным беспокойством, и я хотел бы извлечь уроки из части популярного CMS PHP как Wordpress, Joomla, Drupal, и т.д. Каковы некоторые дефекты безопасности или уязвимости, которые они имеют, они имели в прошлом, которого я могу избежать в своем приложении и какие стратегии я могу использовать для предотвращения их? Каковы другие проблемы, которые я должен быть заинтересован, с которым они, возможно, не столкнулись как уязвимость, потому что они обработали ее правильно от запуска? Какие дополнительные средства защиты или меры Вы включали бы, что-нибудь от мелких подробностей до системных подходов безопасности уровня? Будьте максимально конкретны. Я обычно знаю о большинстве обычных векторов атаки, но я хочу удостовериться, что все основания охвачены, не бойтесь упомянуть очевидное также. Примите PHP 5.2 +.
Править: Я изменяю это на общественную Wiki. Даже при том, что превосходный ответ Arkh принят, я все еще интересуюсь дальнейшими примерами, если у Вас есть они.
7 ответов
Подделка межсайтовых запросов (CSRF)
Описание:
Основная идея состоит в том, чтобы обманом перенаправить пользователя на страницу, где его браузер инициирует запрос POST или GET к CMS вы нападаете.
Представьте, что вы знаете адрес электронной почты администратора сайта, работающего на CMS. Отправьте ему по электронной почте какую-нибудь забавную веб-страницу с тем, что вы хотите. На этой странице вы создаете форму с данными, используемыми административной панелью CMS для создания нового пользователя-администратора. Отправьте эти данные в панель администратора веб-сайта, в результате чего появится скрытый iframe вашей веб-страницы. Вуаля, у вас есть собственная учетная запись администратора.
Как это предотвратить:
Обычный способ - сгенерировать случайный кратковременный (от 15 минут до часа) одноразовый номер во всех ваших формах.Когда ваша CMS получает данные формы, она сначала проверяет, в порядке ли одноразовый номер. В противном случае данные не используются.
Примеры CMS:
Дополнительная информация:
На странице википедии и в проекте OWASP .
Неверное сохранение пароля
Описание:
Представьте, что ваша база данных взломана и опубликована на чем-то вроде wikileak. Зная, что большая часть ваших пользователей использует одни и те же логин и пароль для многих веб-сайтов, вы хотите, чтобы их было легко получить?
Нет. Вам необходимо уменьшить ущерб, нанесенный, если данные вашей базы данных станут общедоступными.
Как это предотвратить:
- Первая идея - хэшировать их. Это плохая идея из-за радужных таблиц (даже если хеш - это не md5, а sha512, например).
- Вторая идея: добавьте уникальную случайную соль перед хешированием, чтобы хакерам приходилось подбирать каждый пароль. Проблема в том, что хакер может быстро вычислить много хешей.
- Итак, текущая идея состоит в том, чтобы замедлить хеширование паролей: вам все равно, потому что вы делаете это нечасто. Но злоумышленник будет плакать, когда он получит от 1000 хэшей, сгенерированных за мс, до 1.
Чтобы упростить процесс, вы можете использовать библиотеку phpass , разработанную каким-то гуру паролей.
Примеры CMS:
- Joomla! : salted md5
- ModX: md5
- Typo3: открытый текст
- Drupal: переключился на phpass после этого обсуждения .
Дополнительная информация:
Страница phpass .
Межсайтовый скриптинг (XSS)
Описание
Цель этих атак - заставить ваш веб-сайт отображать некоторый скрипт, который будет выполняться вашим законным пользователем.
Они бывают двух видов: настойчивые или нет. Первый обычно исходит из того, что ваш пользователь может сохранить, второй рассчитывается на параметры, заданные отправленным запросом. Вот пример, не постоянный:
<?php
if(!is_numeric($_GET['id'])){
die('The id ('.$_GET['id'].') is not valid');
}
?>
Теперь ваш злоумышленник может просто отправлять ссылки типа http://www.example.com/vulnerable.php?id=