Я создаю PHP CMS, который, я надеюсь, будет использоваться общественностью. Безопасность – это серьезная проблема, и я хотел бы изучить некоторые из популярных PHP CMS, таких как WordPress, Joomla, Drupal и т. Д. Каковы некоторые недостатки или уязвимости безопасности, которые у них были в прошлом, которых я могу избежать в своем приложении и какие стратегии я могу использовать, чтобы избежать их? Каковы другие вопросы, которые мне нужно учитывать, что они, возможно, не стали уязвимостью, потому что они правильно справлялись с самого начала? Какие дополнительные функции безопасности или меры вы включили бы, от минимальных деталей до подходов безопасности на уровне системы? Пожалуйста, будьте как можно более конкретными. Я вообще знаю большинство обычных векторов атаки, но я хочу убедиться, что все базы покрыты, поэтому не бойтесь упоминать и очевидное. Предположим, PHP 5.2+.
Изменить : я меняю это на вики сообщества. Несмотря на то, что отличный ответ Арха принят, меня все еще интересуют дальнейшие примеры, если они у вас есть.
Основная идея заключается в том, чтобы обмануть пользователя на странице, где его браузер инициирует запрос POST или GET на атакующую CMS.
Представьте, что вы знаете адрес электронной почты администратора сайта CMS. Отправьте ему по электронной почте какую-нибудь забавную веб-страницу с тем, что вы хотите в ней. На этой странице вы создаете форму с данными, используемыми административной панелью CMS для создания нового пользователя-администратора. Отправьте эти данные на панель администратора веб-сайта, в результате чего будет скрыт iframe вашей веб-страницы. Voilà, вы создали свою собственную учетную запись администратора.
Обычный способ состоит в том, чтобы генерировать случайные кратковременные (15mn-hour) nonce во всех ваших формах. Когда ваша CMS получает данные формы, она проверяет сначала, если nonce в порядке. Если нет, данные не используются.
На странице википедии и в проекте OWASP .
Представьте, что ваша база данных взломана и опубликована на что-то вроде wikileak. Зная, что большая часть ваших пользователей использует один и тот же логин и пароль для большого количества веб-сайтов, вы хотите, чтобы их было легко получить?
Нет. Вам необходимо смягчить ущерб, если ваши базы данных становятся общедоступными.
Чтобы облегчить процесс, вы можете использовать библиотеку phpass, разработанную каким-то паролем-гуру.
Страница phpass .
Цель этих атак заключается в том, чтобы на вашем веб-сайте отображался какой-то скрипт, который будет выполнен вашим законным пользователем.
У вас есть два вида: постоянный или нет. Первый из них обычно происходит от чего-то, что может сохранить ваш пользователь, а другой – для параметров, заданных отправленным запросом. Вот пример, а не постоянный:
<?php if(!is_numeric($_GET['id'])){ die('The id ('.$_GET['id'].') is not valid'); } ?> Теперь ваш злоумышленник может просто отправлять ссылки, такие как http://www.example.com/vulnerable.php?id=<script>alert('XSS')</script>
Вам нужно отфильтровать все, что вы выдаете клиенту. Самый простой способ – использовать htmlspecialchars, если вы не хотите, чтобы ваш пользователь сохранял любой html. Но, когда вы позволяете им выводить html (либо собственный html, либо какой-либо другой, созданный из других вещей, таких как bbcode), вы должны быть очень осторожны. Вот старый пример, использующий событие «onerror» тега img: уязвимость vBulletin . Или у вас есть старый Samys из Myspace .
Вы можете проверить википедию и OWASP . У вас также есть много XSS-вектора на странице ha.ckers .
Почтовые заголовки разделены последовательностью CRLF ( \r\n ). Когда вы используете некоторые данные пользователя для отправки писем (например, используя его для From: или To :), они могут вводить больше заголовков. При этом они могут отправлять анонимные письма с вашего сервера.
Отфильтруйте все символы \n , \r , %0a и %0d в ваших заголовках.
Википедия – это хорошее начало, как обычно.
Старый классик. Это происходит, когда вы формируете SQL-запрос, используя прямой ввод пользователем. Если этот ввод создается, как требуется, пользователь может делать именно то, что он хочет.
Просто. Не формируйте SQL-запросы с пользовательским вводом. Используйте параметризованные запросы . Рассмотрим любой ввод, который не кодируется самим пользователем как пользовательский вход, будь то из файловой системы, вашей собственной базы данных или веб-службы, например.
У Википедии и OWASP есть действительно хорошие страницы на эту тему.
Как и заголовки электронной почты, заголовки http разделены последовательностью CLRF. Если ваше приложение использует вход пользователя для заголовков вывода, они могут использовать его для создания своих собственных.
Как для электронных писем, фильтруйте символы \n , \r , %0a и %0d из пользовательского ввода, прежде чем использовать его как часть заголовка. Вы также можете использовать urlencode для своих заголовков.
Я позволю вам немного догадаться, где можно найти много информации об этой атаке. OWASP и Википедия .
В этом случае злоумышленник хочет использовать сеанс другого законного (и надежно аутентифицированного) пользователя. Для этого он может либо изменить свой собственный cookie сеанса, чтобы он соответствовал одному из жертв, либо может заставить жертву использовать собственный идентификатор сеанса (атакующего).
Здесь нет ничего идеального: – если злоумышленник украдет файл cookie жертвы, вы можете проверить, соответствует ли пользовательский сеанс IP-адресу пользователя. Но это может сделать ваш сайт бесполезным, если законные пользователи используют некоторый прокси-сервер, который часто меняет IP-адрес. – если злоумышленник заставляет пользователя использовать свой собственный идентификатор сеанса, просто используйте session_regenerate_id для изменения идентификатора сеанса пользователя, когда его изменения прав (вход в систему, выход из системы, вход в админ-часть сайта и т. д.).
Википедия на эту тему.
У вас есть много вещей, которые вы можете прочитать на странице OWASP .
Я помню довольно забавный из phpBB. Файл cookie с автологином содержал сериализованный массив, содержащий пользовательский пароль и зашифрованный пароль (без соли). Измените пароль на логическое значение со значением true, и вы можете войти в систему как любой, кем хотите. Вам не нравятся слабые языки?
Еще одна проблема, с которой столкнулся phpBB, была в регулярном выражении для выделения ключевых слов поиска с обратным вызовом (с помощью e modifier ), что позволило вам выполнить собственный PHP-код – например, системные вызовы на незащищенных системах или просто вывести конфигурацию файл, чтобы получить логин / пароль MySQL.
Итак, чтобы рассчитать эту историю:
md5( "secretpass" ) == true ). И, конечно, есть и другие проблемы, о которых я уже говорил.
Еще одна проблема с уровнем безопасности на уровне приложений, с которой я сталкиваюсь, связана с недостаточным авторизацией доступа к страницам или функциям. Другими словами, безопасность устанавливается только показом ссылок, когда вам разрешено просматривать эти ссылки, но не полностью проверяет, разрешено ли учетной записи пользователя просматривать страницу или использовать ее, как только они находятся на странице.
Другими словами, у учетной записи администратора есть ссылки, отображаемые для перехода на страницы управления пользователями. Но на странице управления пользователями проверяется, что пользователь вошел в систему, а не то, что они вошли в систему и администратор. Затем обычный пользователь регистрируется, вручную вводит в URI-страницу администратора, затем имеет полный доступ администратора к страницам управления пользователями и делает свою учетную запись в учетной записи администратора.
Вы будете удивлены, сколько раз я видел такие вещи даже в приложениях корзины покупок, где пользовательские данные CC доступны для просмотра.
Самый большой, который так много людей, кажется, забывает или не понимает, – это то, что каждый может публиковать любые данные в ваших сценариях, включая файлы cookie и сеансы и т. Д. И не забывайте, что только потому, что пользователь вошел в систему, это не значит, что они может делать какие-либо действия.
Например, если у вас есть скрипт, который обрабатывает добавление / редактирование комментария, у вас может быть следующее:
if ( userIsLoggedIn() ) { saveComment( $_POST['commentid'], $_POST['commenttext'] ) }
Вы видите, что случилось? Вы проверили, что пользователь вошел в систему, но вы не проверяли, владеет ли пользователь комментарием или он может редактировать комментарий. Это означает, что любой зарегистрированный пользователь может опубликовать комментарий и содержимое комментария и отредактировать комментарии других пользователей!
Еще одна вещь, которую следует помнить при предоставлении программного обеспечения другим, – это то, что настройки сервера сильно различаются. Когда данные отправляются, вы можете сделать это, например:
if (get_magic_quotes_gpc()) $var = stripslashes($_POST['var']); else $var = $_POST['var'];
Так много …
В нескольких ответах здесь перечислены конкретные волки, которые они помнят, или общие «вещи, о которых я беспокоюсь при написании веб-приложения», но если вы хотите получить достаточно надежный список большинства зарегистрированных уязвимостей, найденных исторически, то вы не будете делать намного хуже, чем для поиска Национальной базы данных уязвимостей
В Joomla или Joomla addons имеется 582 уязвимости, 199 для WordPress и 345 для Drupal для переваривания.
Для общего понимания общих webapp vuls, проект OWASP Top Ten был недавно обновлен и является важным для любого веб-разработчика.
Четыре больших в моем сознании:
Запретить POST из других доменов / IP So Bots can not login / submit forms.
Люди , это ответы, самый большой секретный затвор, – это человеческая глупость . Доверяйте , просмотрите код. Вам нужна специальная команда, которая рассмотрит все, что добавлено в качестве дополнительного кода в вашем приложении, проблема cms – это аутсорсинг, входящие сообщения, WordPress, Drupal, Joomla и другие популярные cms, такие как установки по умолчанию, они действительно находятся в очень хорошая точка безопасности. Проблема возникает, когда вы оставляете людей добавлять дополнительный код в свое приложение без хорошего обзора (или лучше, без тестирования на проникновение). Это тот момент, когда у WordPress и Joomla есть слабость, есть так много плагинов n deves, есть так много утверждений, сотни устаревших плагинов n тем outhere …. Так imho, если вы можете построить сильную команду , хороший план безопасности, обучите своих участников и узнайте, как безопасно кодировать код и со всеми остальными комментариями перед моим, тогда вы сможете двигаться дальше и говорить: ei hi, это мои cms, и это немного более безопасно чем все остальные cms в сети;)
Вот потенциальная ловушка для админов форума, особенно тех, кто кодирует форму с помощью селектора выпадающего списка, но не подтверждает, что опубликованный ответ был фактически одним из доступных вариантов.
В колледже я понял, что пользовательский селектор страны в phpBB не имеет такой проверки.
На нашем школьном форуме вместо «Соединенных Штатов» или «Афганистана» моя страна могла бы быть НИЧЕГО, как бы ни глупо, ни грязно. Все, что мне нужно, это html POST-форма. Мне потребовалось несколько дней, чтобы понять, как я это сделал, но вскоре у всех «классных детей» были смешные фразы, а не страны, отображаемые под их именами пользователей.
Пойти в колледж по искусству было потрясающе. : D