Подделка межсайтовых запросов (CSRF)
Описание:
Основная идея состоит в том, чтобы обмануть пользователя на странице, где его браузер инициирует запрос POST или GET к CMS, на которую вы нападаете.
Представьте, что вы знаете электронную почту администратора сайта с поддержкой CMS. Напишите ему какую-нибудь забавную веб-страницу с тем, что хотите. На этой странице вы создаете форму с данными, которые используются административной панелью CMS для создания нового пользователя-администратора. Отправьте эти данные на панель администратора сайта, в результате чего в вашей веб-странице будет скрытый фрейм.
Вуаля, вы создали собственную учетную запись администратора.
Как это предотвратить:
Обычный способ - генерировать случайные кратковременные одноразовые номера (от 15 до час) во всех ваших формах. Когда ваша CMS получает данные формы, она сначала проверяет, в порядке ли одноразовый номер. Если нет, данные не используются.
Примеры CMS:
Дополнительная информация:
На странице википедии и в проекте OWASP .
Неверное хранение пароля
Описание:
Представьте, что ваша база данных взломана и опубликована на что-то вроде wikileak. Зная, что большая часть ваших пользователей используют одни и те же логин и пароль для многих веб-сайтов, вы хотите, чтобы их было легко получить?
Нет. Вам необходимо уменьшить нанесенный ущерб, если данные вашей базы данных станут общедоступными.
Как это предотвратить:
- Первая идея состоит в том, чтобы хэшировать их. Что является плохой идеей из-за радужных таблиц (даже если хеш не md5, а, например, sha512).
- Вторая идея: добавьте уникальную случайную соль перед хэшированием, чтобы хакеры взломали каждый пароль. Проблема в том, что хакер может быстро вычислить много хешей.
- Итак, текущая идея состоит в том, чтобы сделать хэширование паролей медленным: вам все равно, потому что вы делаете это не часто. Но злоумышленник будет плакать, когда он получит от 1000 хэшей, генерируемых за мс, до 1.
Чтобы упростить процесс, вы можете использовать библиотеку phpass , разработанную каким-то гуру паролей.
Примеры CMS:
Дополнительная информация:
Страница 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 . Или у вас есть старая Myspace's Samy .
Примеры CMS:
Дополнительная информация:
Вы можете проверить Википедию и OWASP . У вас также есть много XSS-векторов на странице ha.ckers .
Инъекция заголовка почты
Описание:
Почтовые заголовки разделены последовательностью CRLF (\r\n). Когда вы используете некоторые пользовательские данные для отправки писем (например, используя их для From: или To :), они могут добавить больше заголовков. При этом они могут отправлять анонимные письма с вашего сервера.
Как это предотвратить:
Отфильтруйте все символы \n, \r, %0a и %0d в заголовках.
Примеры CMS:
Дополнительная информация:
Википедия - хорошее начало, как обычно.
SQL-инъекция
Описание:
Старая классика. Это происходит, когда вы формируете SQL-запрос, используя прямой ввод данных пользователем. Если этот ввод создается как нужно, пользователь может делать именно то, что он хочет.
Как это предотвратить:
Simple. Не формируйте SQL-запросы с пользовательским вводом. Используйте параметризованные запросы .
Рассматривайте любые входные данные, которые сами не кодируются как пользовательские, например, из файловой системы, из вашей собственной базы данных или веб-службы.
Пример CMS:
Дополнительная информация:
Википедия и OWASP имеют действительно хорошие страницы по теме.
Http-ответ разделения
Описание:
Как и заголовки электронной почты, заголовки http разделяются последовательностью CLRF. Если ваше приложение использует пользовательский ввод для вывода заголовков, они могут использовать его для создания своих собственных.
Как это предотвратить:
Как и для электронных писем, фильтруйте \n, \r, %0a и %0d символов из пользовательского ввода, прежде чем использовать его как часть заголовка. Вы также можете urlencode свои заголовки.
Примеры CMS:
Дополнительная информация:
Я позволю вам немного догадаться, где можно найти много информации об этом виде атаки. OWASP и Википедия .
Захват сессии
Описание:
В этом случае злоумышленник хочет использовать сеанс другого законного (и, надеюсь, прошедшего проверку подлинности) пользователя.
Для этого он может либо изменить свой собственный файл cookie сеанса, чтобы он соответствовал файлу жертвы, либо он может заставить жертву использовать собственный идентификатор сеанса (атакующего).
Как это предотвратить:
Ничто не может быть идеальным здесь:
- если злоумышленник украл файл cookie жертвы, вы можете проверить, соответствует ли сеанс пользователя IP-адресу пользователя. Но это может сделать ваш сайт бесполезным, если законные пользователи используют некоторые прокси, которые часто меняют IP.
- если злоумышленник заставляет пользователя использовать свой собственный идентификатор сеанса, просто используйте session_regenerate_id , чтобы изменить идентификатор сеанса пользователя при изменении его прав (вход в систему, выход из системы, вход в административную часть сайта и т. д.).
Примеры CMS:
Дополнительная информация:
Википедия страница по теме.
Другое
- User DoSing: если вы предотвращаете грубое использование попытки входа в систему, отключая пробные имена пользователей, а не IP-адреса, с которых поступают попытки, любой может заблокировать всех ваших пользователей за 2 мин. То же самое при создании новых паролей: не отключайте старый, пока пользователь не подтвердит новый (например, войдя в него).
- Использование пользовательского ввода, чтобы сделать что-то в вашей файловой системе. Фильтруйте это, как будто это рак, смешанный со СПИДом. Это касается использования include и require для файлов, путь которых частично определяется из пользовательского ввода.
- Использование eval , system , exec или чего-либо подобного с пользовательским вводом.
- Не помещайте файлы, которые вам не нужны, в веб-каталог.
На странице OWASP вы можете прочитать множество вещей.