Исторические недостатки безопасности популярных PHP CMS?

Я создаю PHP CMS, который, я надеюсь, будет использоваться общественностью. Безопасность – это серьезная проблема, и я хотел бы изучить некоторые из популярных PHP CMS, таких как WordPress, Joomla, Drupal и т. Д. Каковы некоторые недостатки или уязвимости безопасности, которые у них были в прошлом, которых я могу избежать в своем приложении и какие стратегии я могу использовать, чтобы избежать их? Каковы другие вопросы, которые мне нужно учитывать, что они, возможно, не стали уязвимостью, потому что они правильно справлялись с самого начала? Какие дополнительные функции безопасности или меры вы включили бы, от минимальных деталей до подходов безопасности на уровне системы? Пожалуйста, будьте как можно более конкретными. Я вообще знаю большинство обычных векторов атаки, но я хочу убедиться, что все базы покрыты, поэтому не бойтесь упоминать и очевидное. Предположим, PHP 5.2+.

Изменить : я меняю это на вики сообщества. Несмотря на то, что отличный ответ Арха принят, меня все еще интересуют дальнейшие примеры, если они у вас есть.

Подделка запросов на межсайтовый запрос (CSRF)

Описание :

Основная идея заключается в том, чтобы обмануть пользователя на странице, где его браузер инициирует запрос POST или GET на атакующую CMS.

Представьте, что вы знаете адрес электронной почты администратора сайта CMS. Отправьте ему по электронной почте какую-нибудь забавную веб-страницу с тем, что вы хотите в ней. На этой странице вы создаете форму с данными, используемыми административной панелью CMS для создания нового пользователя-администратора. Отправьте эти данные на панель администратора веб-сайта, в результате чего будет скрыт iframe вашей веб-страницы. Voilà, вы создали свою собственную учетную запись администратора.

Как предотвратить это:

Обычный способ состоит в том, чтобы генерировать случайные кратковременные (15mn-hour) nonce во всех ваших формах. Когда ваша CMS получает данные формы, она проверяет сначала, если nonce в порядке. Если нет, данные не используются.

Примеры CMS:

  • CMS прост
  • Joomla!
  • Drupal
  • ModX

Больше информации :

На странице википедии и в проекте OWASP .

Неверное хранение паролей

Описание :

Представьте, что ваша база данных взломана и опубликована на что-то вроде wikileak. Зная, что большая часть ваших пользователей использует один и тот же логин и пароль для большого количества веб-сайтов, вы хотите, чтобы их было легко получить?

Нет. Вам необходимо смягчить ущерб, если ваши базы данных становятся общедоступными.

Как предотвратить это:

  • Первой идеей является их хэш. Это плохая идея из-за радужных таблиц (даже если хэш не md5, а sha512, например).
  • Вторая идея: добавьте уникальную случайную соль перед хешированием, чтобы хакеры должны были набросать каждый пароль. Проблема в том, что хакер может быстро вычислить хэш.
  • Итак, текущая идея заключается в том, чтобы замедлить использование хэшей паролей: вам все равно, потому что вы не часто это делаете. Но атакующий будет плакать, когда он получит от 1000 хешей, сгенерированных за мс до 1.

Чтобы облегчить процесс, вы можете использовать библиотеку phpass, разработанную каким-то паролем-гуру.

Примеры CMS:

  • Joomla! : соленое md5
  • ModX: md5
  • Typo3: cleartext
  • Drupal: после этого обсуждения переключился на phpass.

Больше информации :

Страница phpass .

Кросс-сайт Scripting (XSS)

Описание

Цель этих атак заключается в том, чтобы на вашем веб-сайте отображался какой-то скрипт, который будет выполнен вашим законным пользователем.

У вас есть два вида: постоянный или нет. Первый из них обычно происходит от чего-то, что может сохранить ваш пользователь, а другой – для параметров, заданных отправленным запросом. Вот пример, а не постоянный:

<?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 .

Примеры CMS:

  • CMS прост
  • Mura CMS
  • Drupal
  • ModX

Больше информации :

Вы можете проверить википедию и OWASP . У вас также есть много XSS-вектора на странице ha.ckers .

Ввод заголовка письма

Описание :

Почтовые заголовки разделены последовательностью CRLF ( \r\n ). Когда вы используете некоторые данные пользователя для отправки писем (например, используя его для From: или To :), они могут вводить больше заголовков. При этом они могут отправлять анонимные письма с вашего сервера.

Как предотвратить это:

Отфильтруйте все символы \n , \r , %0a и %0d в ваших заголовках.

Примеры CMS:

  • Jetbox CMS

Больше информации :

Википедия – это хорошее начало, как обычно.

SQL-инъекция

Описание :

Старый классик. Это происходит, когда вы формируете SQL-запрос, используя прямой ввод пользователем. Если этот ввод создается, как требуется, пользователь может делать именно то, что он хочет.

Как предотвратить это:

Просто. Не формируйте SQL-запросы с пользовательским вводом. Используйте параметризованные запросы . Рассмотрим любой ввод, который не кодируется самим пользователем как пользовательский вход, будь то из файловой системы, вашей собственной базы данных или веб-службы, например.

Пример CMS:

  • Drupal
  • Joomla!
  • ModX
  • Pars CMS

Больше информации :

У Википедии и OWASP есть действительно хорошие страницы на эту тему.

Разделение ответа Http

Описание :

Как и заголовки электронной почты, заголовки http разделены последовательностью CLRF. Если ваше приложение использует вход пользователя для заголовков вывода, они могут использовать его для создания своих собственных.

Как предотвратить это:

Как для электронных писем, фильтруйте символы \n , \r , %0a и %0d из пользовательского ввода, прежде чем использовать его как часть заголовка. Вы также можете использовать urlencode для своих заголовков.

Примеры CMS:

  • Дрейк CMS
  • Plone CMS
  • WordPress

Больше информации :

Я позволю вам немного догадаться, где можно найти много информации об этой атаке. OWASP и Википедия .

Захват сеанса

Описание :

В этом случае злоумышленник хочет использовать сеанс другого законного (и надежно аутентифицированного) пользователя. Для этого он может либо изменить свой собственный cookie сеанса, чтобы он соответствовал одному из жертв, либо может заставить жертву использовать собственный идентификатор сеанса (атакующего).

Как предотвратить это:

Здесь нет ничего идеального: – если злоумышленник украдет файл cookie жертвы, вы можете проверить, соответствует ли пользовательский сеанс IP-адресу пользователя. Но это может сделать ваш сайт бесполезным, если законные пользователи используют некоторый прокси-сервер, который часто меняет IP-адрес. – если злоумышленник заставляет пользователя использовать свой собственный идентификатор сеанса, просто используйте session_regenerate_id для изменения идентификатора сеанса пользователя, когда его изменения прав (вход в систему, выход из системы, вход в админ-часть сайта и т. д.).

Примеры CMS:

  • Joomla! и Drupal
  • Zen Cart

Больше информации :

Википедия на эту тему.

Другие

  • User DoSing: если вы предотвратите грубую попытку входа в систему, отключив имена пользователей, а не IP-запросы, каждый может заблокировать всех ваших пользователей в 2 млн. То же самое при создании новых паролей: не отключайте старый, пока пользователь не подтвердит новый (например, путем входа в систему).
  • Используя пользовательский ввод, чтобы что-то сделать в вашей файловой системе. Отфильтруйте это, как если бы он был раком, смешанным с пособиями. Это касается использования include и require на файлах, путь которых частично сделан из пользовательского ввода.
  • Используя eval , system , exec или что-нибудь в этом роде с пользовательским вводом.
  • Не помещайте файлы, которые вам не нужны, в Интернете, доступном в веб-каталоге.

У вас есть много вещей, которые вы можете прочитать на странице OWASP .

Я помню довольно забавный из phpBB. Файл cookie с автологином содержал сериализованный массив, содержащий пользовательский пароль и зашифрованный пароль (без соли). Измените пароль на логическое значение со значением true, и вы можете войти в систему как любой, кем хотите. Вам не нравятся слабые языки?

Еще одна проблема, с которой столкнулся phpBB, была в регулярном выражении для выделения ключевых слов поиска с обратным вызовом (с помощью e modifier ), что позволило вам выполнить собственный PHP-код – например, системные вызовы на незащищенных системах или просто вывести конфигурацию файл, чтобы получить логин / пароль MySQL.

Итак, чтобы рассчитать эту историю:

  • Следите за тем, чтобы PHP был слабым ( md5( "secretpass" ) == true ).
  • Будьте осторожны со всем кодом, который можно использовать в обратном вызове (или, что еще хуже, eval).

И, конечно, есть и другие проблемы, о которых я уже говорил.

Еще одна проблема с уровнем безопасности на уровне приложений, с которой я сталкиваюсь, связана с недостаточным авторизацией доступа к страницам или функциям. Другими словами, безопасность устанавливается только показом ссылок, когда вам разрешено просматривать эти ссылки, но не полностью проверяет, разрешено ли учетной записи пользователя просматривать страницу или использовать ее, как только они находятся на странице.

Другими словами, у учетной записи администратора есть ссылки, отображаемые для перехода на страницы управления пользователями. Но на странице управления пользователями проверяется, что пользователь вошел в систему, а не то, что они вошли в систему и администратор. Затем обычный пользователь регистрируется, вручную вводит в 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 был недавно обновлен и является важным для любого веб-разработчика.

  • A1: Инъекция
  • A2: Межсайтовый скриптинг (XSS)
  • A3: Сломанная аутентификация и управление сеансом
  • A4: Небезопасные ссылки на прямые объекты
  • A5: Подделка запросов на межсайтовый запрос (CSRF)
  • A6: Неверная настройка безопасности
  • A7: Небезопасное криптографическое хранилище
  • A8: отказ от ограничения доступа к URL
  • A9: Недостаточная защита транспортного уровня
  • A10: Неопределенные переадресации и форварды

Четыре больших в моем сознании:

  • используя exec на ненадежных данных / коде (или вообще)
  • включение файлов из удаленного URL для локального выполнения
  • позволяя глобальные регистры регистров, чтобы получающие и постпеременные переменные автоматически присваивали значения переменных.
  • не избежание введенных данных db / допускающих атаки SQL-инъекций (обычно это происходит, когда не используется уровень API-интерфейса DB)

Запретить 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