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

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

Описание :

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

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

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

Обычный способ — генерировать случайное короткоживущее (от 15 минут до часа) одноразовое значение во всех ваших формах. Когда ваша CMS получает данные формы, она сначала проверяет, в порядке ли одноразовый номер. В противном случае данные не используются.

Примеры CMS:

• CMS стала проще
• Joomla!
• Drupal
• ModX

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

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

Сохранение неверного пароля

Описание :

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

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

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

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

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

Примеры CMS:

• Джумла! : соленый md5
• ModX: md5
• Опечатка 3 : открытый текст
• 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=<script>alert('XSS')</script>

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

Вам нужно фильтровать все, что вы выводите клиенту. Самый простой способ — использовать htmlspecialchars, если вы не хотите, чтобы ваш пользователь сохранить любой html. Но когда вы позволяете им выводить html (либо их собственный html, либо сгенерированный из других вещей, таких как bbcode), вы должны быть очень осторожны. Вот старый пример использования события onerror тега img: уязвимость vBulletin. Или у вас есть старый Samy с 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:

• Друпал
• Joomla!
• ModX
• CMS Pars

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

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

Разделение HTTP-ответа

Описание :

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

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

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

Примеры CMS:

• Система управления контентом Drake
• Plone CMS
• Wordpress

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

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

Перехват сеанса

Описание :

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

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

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

Примеры CMS:

• Joomla! и Drupal
• Корзина Zen

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

страница Википедии по этому вопросу.

Другой

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

Вы можете многое прочитать на странице OWASP.

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

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

Итак, подытоживая эту историю:

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

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

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

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

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

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

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

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

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

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

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

Так много..

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

Сообщается о 582 уязвимостях в Joomla или надстройках Joomla, 199 для Wordpress и 345 для Drupal.

Для общего понимания распространенных vuls веб-приложений недавно был опубликован десять лучших проектов OWASP. обновляется и является важным чтением для любого веб-разработчика.

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

Четыре больших в моей голове:

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

Запретить POST с другого домена/IP-адреса, чтобы боты не могли входить в систему/отправлять формы.

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

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

В колледже я понял, что пользовательский селектор страны в phpBB не имеет такой проверки.

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

Поступить в колледж для гиков было здорово. :D