SSRF (Server-Side Request Forgery) — это уязвимость, при которой злоумышленник заставляет сервер отправлять запросы туда, куда он сам не должен обращаться. На первый взгляд проблема может казаться локальной, но на практике SSRF нередко становится точкой входа во внутреннюю сеть, облачную инфраструктуру и административные сервисы.
Как работает SSRF
Обычно приложение принимает URL от пользователя, а затем само загружает ресурс: картинку, webhook, PDF, метаданные или внешний API. Если проверка адреса реализована плохо, атакующий подставляет вместо безопасного URL внутренний адрес, например:
- http://127.0.0.1
- http://localhost
- адреса из приватных подсетей
- облачные metadata endpoint’ы
Сервер делает запрос “от своего имени”, а значит получает доступ к ресурсам, которые извне недоступны.
Чем опасна SSRF
- доступ к внутренним API и админ-панелям
- сканирование внутренних портов и сервисов
- утечка служебных данных
- получение облачных токенов через metadata-сервисы
- обход сетевых ограничений и сегментации
- в некоторых сценариях — путь к RCE ⚠️
Где встречается
- импорт по ссылке
- парсинг внешних страниц
- генерация превью изображений
- интеграции с webhook
- загрузка файлов по URL
- серверные проверки “жив ли сайт”
Типичный сценарий атаки
Приложение умеет “проверить картинку по ссылке”. Пользователь отправляет не внешний URL, а адрес внутреннего сервиса. Сервер обращается к нему и:
- либо возвращает ответ злоумышленнику
- либо косвенно подтверждает существование сервиса по статус-коду, времени ответа, ошибке
Даже “слепая” SSRF без выдачи тела ответа всё равно опасна: по побочным признакам можно картографировать инфраструктуру.
Как защищаться
- не принимать произвольные URL без строгой необходимости
- использовать allowlist доменов, а не denylist
- запрещать обращения к localhost, 127.0.0.1, приватным и link-local диапазонам
- учитывать DNS rebinding и повторно проверять конечный IP
- ограничивать исходящие соединения сервера через firewall/egress rules
- блокировать доступ к metadata endpoints в облаке ☁️
- отключать автоматические редиректы или валидировать каждый шаг
- разделять сетевые роли сервисов по принципу минимальных привилегий
Что важно для разработчиков и DevOps
SSRF — это не только баг в коде, но и архитектурный риск. Даже если приложение уязвимо, грамотная сеть, egress-фильтрация и изоляция сервисов могут не дать атаке перерасти в компрометацию инфраструктуры.
Вывод
SSRF опасна тем, что использует доверие к самому серверу. Для атакующего ваш backend становится прокси во внутренний контур. Поэтому защита должна быть многоуровневой: валидация URL, сетевые ограничения, контроль DNS и защита облачных сервисов 🔐
👀 Ниже стоит посмотреть подборку каналов про IT — там много полезного по безопасности, разработке и инфраструктуре.