Адрес — такой же ввод, как поле формы
Пользователь, а тем более злоумышленник, может отправить любое значение в любом сегменте адреса. Если приложение подставляет слаг в запрос к базе, в путь к файлу или в текст ответа без проверки, каждый такой сегмент становится точкой атаки.
Типичные угрозы
- внедрение в запрос к базе данных через слаг;
- выход за пределы каталога при подстановке в путь к файлу;
- внедрение скрипта, если слаг выводится на страницу без экранирования;
- перенаправление на посторонний сайт через параметр адреса возврата.
Параметризованные запросы вместо склейки строк
// Опасно: склейка строки
db.query("SELECT * FROM posts WHERE slug = '" + slug + "'");
// Безопасно: параметризованный запрос
db.query("SELECT * FROM posts WHERE slug = ?", [slug]);Проверка формата до обращения к данным
Слаг имеет чёткий допустимый вид, поэтому его можно проверить регулярным выражением ещё в описании маршрута. Всё, что не соответствует шаблону, отсекается, и до базы данных запрос не доходит. Пример проверки описан в статье про регулярные выражения для адресов.
^[a-z0-9]+(?:-[a-z0-9]+)*$Осторожно с адресами возврата
Правило: перенаправлять можно только на адреса собственного сайта. Внешний адрес из параметра — прямая дорога к фишингу и потере доверия поисковых систем.
Заголовки ответа как дополнительная защита
Помимо проверки входных данных полезно добавить заголовки, ограничивающие последствия возможных ошибок. Политика безопасности содержимого запрещает исполнение посторонних скриптов, а запрет определения типа содержимого защищает от подмены. Подробнее об этом — в статье про заголовки безопасности.
- экранируйте любые значения перед выводом на страницу;
- не показывайте в ошибках подробности внутреннего устройства;
- ограничивайте размер и число параметров в запросе.
Утечка информации через адреса
Идентификаторы в адресе позволяют перебирать чужие записи, если сервер не проверяет права. Даже при закрытом разделе обращение по угаданному номеру может вернуть чужие данные. Поэтому проверка доступа выполняется всегда на сервере, а не только скрытием ссылок в интерфейсе.
Журналирование подозрительных запросов
Попытки подставить в адрес служебные символы, длинные строки и фрагменты запросов стоит записывать отдельно. Такие записи помогают вовремя заметить целенаправленный взлом и заблокировать источник. Сами записи храните ограниченное время и не выводите их пользователям.
Частые вопросы
Почему сегмент адреса нельзя считать безопасным?
Его значение полностью контролирует отправитель запроса, поэтому его нужно проверять так же тщательно, как любой пользовательский ввод.
Как защититься от внедрения через слаг?
Использовать параметризованные запросы вместо склейки строк и проверять формат слага регулярным выражением.
Можно ли перенаправлять пользователя по адресу из параметра?
Только если адрес принадлежит вашему сайту; внешние адреса из параметров использовать нельзя.
Готовый адрес можно собрать прямо сейчас: откройте генератор ЧПУ — он транслитерирует фразу по таблице Яндекса, уберёт служебные слова и покажет длину адреса.