SSRF (подделка запросов на стороне сервера) — уязвимость, которая позволяет заставить сервер отправлять запросы по адресам атакующего, в том числе во внутренние системы, закрытые от интернета.
Как работает SSRF
Многие приложения загружают ресурсы по URL: строят превью ссылок, импортируют изображения, вызывают вебхуки или конвертируют страницы в PDF. Если сервер не ограничивает, куда может подключаться, атакующий передаёт адрес вроде http://localhost/admin, внутренний IP или облачный сервис метаданных 169.254.169.254. Запрос исходит от доверенного сервера, поэтому межсетевые экраны его пропускают, а внутренние сервисы считают легитимным. Слабость описана как CWE-918.
Почему это важно
- Кража облачных ключей — сервисы метаданных AWS, Azure и Google Cloud могут вернуть временные ключи доступа. При взломе Capital One в 2019 году SSRF позволила получить такие ключи и украсть данные более 100 миллионов клиентов.
- Доступ к внутренним сервисам — админ-панелям, базам данных, API Kubernetes и другим системам за периметром.
- Развитие атаки — в сочетании с другими ошибками SSRF ведёт к удалённому выполнению кода; цепочка ProxyLogon против Microsoft Exchange начиналась именно с SSRF.
В 2021 году SSRF выделили в отдельную категорию OWASP Top 10. По сути, уязвимый сервер становится прокси для атакующего и резко расширяет доступную ему поверхность атаки. В отличие от атаки «человек посередине», SSRF не требует позиции в сети — достаточно уязвимой функции.
Как предотвратить
- Разрешать исходящие запросы только к белому списку доменов и протоколов, не полагаясь лишь на чёрные списки.
- Определять и проверять IP-адрес назначения, блокировать частные, loopback- и link-local-диапазоны, в том числе после перенаправлений.
- Использовать IMDSv2 в AWS и аналогичные механизмы в других облаках.
- Выносить компоненты, загружающие URL, в отдельный сегмент со строгими правилами исходящего трафика.
Как и другие уязвимости веб-приложений, SSRF помогает выявить регулярное тестирование безопасности.
