Подтвердить что ты не робот

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

Описание:

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

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

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

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

Примеры CMS:

Дополнительная информация:

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

Неверное сохранение пароля

Описание:

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

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

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

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

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

Примеры CMS:

Дополнительная информация:

астральная страница.

Скрипты между сайтами (XSS)

Описание

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

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

<?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. Или у вас есть старый Myspace Samy.

Примеры CMS:

Дополнительная информация:

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

Ввод заголовка заголовка

Описание:

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

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

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

Примеры CMS:

Дополнительная информация:

Wikipedia - это хороший старт, как обычно.

SQL Injection

Описание:

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

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

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

Пример CMS:

Дополнительная информация:

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

Отклонение ответа Http

Описание:

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

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

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

Примеры CMS:

Дополнительная информация:

Я расскажу вам немного о том, где вы можете найти много информации об этой атаке. OWASP и Wikipedia.

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

Описание:

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

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

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

Примеры CMS:

Дополнительная информация:

Wikipedia на эту тему.

Другие

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

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

Ответ 2

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

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

Итак, чтобы подвести итог этой истории:

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

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

Ответ 3

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

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

Вы будете удивлены, сколько раз я видел такие вещи даже в приложениях корзины покупок, где доступны данные пользовательского CC.

Ответ 4

Так много..

Несколько ответов здесь перечисляют конкретные волки, которые они помнят, или общие "вещи, о которых я беспокоюсь при написании webapp", но если вы хотите получить достаточно надежный список большинства зарегистрированных уязвимостей, найденных исторически, тогда вы не сделали бы намного хуже, чем поиск Национальная база данных уязвимостей

В Joomla или Joomla addons имеется 582 уязвимости, 199 для Wordpress и 345 для Drupal для вас.

Для общего понимания общих webapp vuls, OWASP Top Ten project недавно был обновлен и является важным для любого веб-разработчика.

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

Ответ 5

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

Например, если у вас есть script, который обрабатывает добавление/редактирование комментария, у вас может быть следующее:

if ( userIsLoggedIn() ) {
    saveComment( $_POST['commentid'], $_POST['commenttext'] )
}

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

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

if (get_magic_quotes_gpc())
    $var = stripslashes($_POST['var']);
else
    $var = $_POST['var'];

Ответ 6

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

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

Ответ 7

Запретить POST из другого домена /IP. Таким образом, боты не могут вводить/отправлять формы.

Ответ 8

Люди, самая большая казнь безопасности, это человеческая глупость. Доверьтесь, просмотрите код. Вам нужна специальная команда, которая рассмотрит все, что добавлено в качестве дополнительного кода в ваше приложение, проблема с cms - это аутсорсинг, поступления, WordPress, Drupal, Joomla и другие популярные cms, такие как установки по умолчанию, они действительно находятся в очень хорошая точка безопасности. Проблема возникает, когда вы оставляете людей добавлять дополнительный код в ваше приложение, без хорошего обзора (или лучше, без тестирования на проникновение). В этом и заключается слабость WordPress и Joomla, так много плагинов и разработчиков тем, так много одобрений, сотни устаревших плагинов и тем. Так что, если вы в состоянии создать сильную команду, хороший план безопасности, обучите своих участников и научите их, как защищать код, и со всеми другими комментариями до моего выступления, тогда вы сможете двигаться дальше и сказать: "Эй, привет, мои cms, и это немного более безопасно" чем все остальные смс в сети;)

Ответ 9

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

В колледже я понял, что селектор user 'country' в phpBB не имеет такой проверки.

В нашем школьном форуме вместо "Соединенных Штатов" или "Афганистана" моя страна могла бы быть НИЧЕГО, как бы ни глупо, ни грязно. Все, что мне нужно, это html POST-форма. Мои одноклассники несколько дней выяснили, как я это сделал, но вскоре у всех "классных детей" были смешные фразы, а не страны, отображаемые под их именами пользователей.

Поездка в колледж-выродка была потрясающей.: D