SSRF возникает, когда недоверенные данные заставляют сервер обращаться к непредусмотренному адресу с его сетевыми возможностями. Защита включает ограничение разрешенных назначений, схем и портов, проверку DNS и перенаправлений, а также сетевой контроль исходящих соединений. Одной проверки строки URL недостаточно.
В чем суть SSRF?
Как управление назначением серверного запроса нарушает границу доверия и какие уровни защиты нужны для URL, DNS, перенаправлений и исходящего трафика.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
SSRF, Server-Side Request Forgery, возникает, когда приложение формирует серверный запрос под влиянием недоверенных данных и допускает обращение к непредусмотренному назначению. Например, функция загрузки внешнего ресурса должна получать только допустимые данные, а не предоставлять клиенту произвольный сетевой доступ от имени сервера. Суть класса описана в OWASP API Security.
Ключевая проблема — различие доверия и возможностей: сервер может иметь доступ к ресурсам, недоступным пользователю напрямую. Последствием бывает раскрытие информации, нежелательное действие внутреннего сервиса или расход ресурсов. Ответ сервера не обязательно должен возвращаться пользователю, чтобы небезопасное обращение имело последствия.
Защита начинается с ограничения функциональности. Если набор назначений известен, используйте список разрешенных адресатов и поддерживаемых схем и портов. Разбирайте URL надежным парсером, а не проверкой наличия нужной подстроки.
Далее учитывайте разрешение DNS и фактический адрес соединения, включая IPv4 и IPv6. Проверка имени не должна расходиться с адресом, к которому в итоге подключается клиент. Автоматические перенаправления лучше отключать; если они нужны, каждое новое назначение должно проходить те же проверки.
На сетевом уровне ограничивайте исходящие соединения сервиса необходимыми направлениями. Такая многоуровневая защита, включая контроль DNS и redirect, рассматривается в рекомендациях OWASP. Дополнительно нужны лимиты времени и размера ответа, минимальные полномочия и безопасное журналирование.
Проверки выполняют только на разрешенном стенде с контролируемыми адресатами. Наличие входного firewall или аутентификации пользователя само по себе не решает проблему: опасный запрос исходит от доверенного серверного компонента.