Глоссарий
Что такое SSRF (Server-Side Request Forgery)
SSRF заставляет сервер отправлять запросы к внутренним назначениям, до которых он не должен доставать (внутренние IP, облачные метаданные) — точка входа утечки Capital One. Как это работает, где оно прячется, какие подводные камни валидации упускают и как защищаться.
«Вставьте URL, и мы загрузим его содержимое» — повседневное удобство, которое в худшем случае становится дверью к вашим облачным учётным данным. Это и есть SSRF. Вот как он работает и как защищаться, с нуля.
Что на самом деле происходит
Обычный доступ — «пользователь → внешний сайт». SSRF превращает сервер в прокси, обращающийся внутрь. Серверы могут доставать до внутренних сетей и эндпоинтов облачных учётных данных, невидимых снаружи — поэтому атакующий подсматривает в них косвенно.
169.254.169.254 (облачные учётные данные)В облаке этот внутренний эндпоинт (сервис метаданных) может выдать временные учётные данные. Если SSRF до него дотянется, ключи крадут, и атака цепляется к массовому выносу хранилища — именно это произошло в утечке Capital One (2019): SSRF → метаданные → учётные данные IAM → S3.
Где он прячется
Любая функция, где «сервер загружает URL от пользователя», — кандидат.
| Функция | Типичная реализация |
|---|---|
| OG / превью ссылки | сервер загружает вставленный URL, чтобы построить миниатюру |
| Доставка вебхуков | сервер делает POST на заданное пользователем назначение |
| Импорт изображения / файла | «загрузить изображение по URL» |
| Диагностика сайта | сервер обращается к введённому сайту, чтобы его осмотреть |
Подводные камни валидации, которые упускают
«Блокировать внутренние IP» недостаточно. Нужно закрыть и эти бреши.
Наивная блокировка протекает
- Следование за редиректами: разрешённый домен делает
302на внутренний адрес. - DNS rebinding: внешний IP в момент валидации, внутренний IP в момент загрузки.
- Трюки с кодированием IP: десятичные/восьмеричные/сокращённые формы маскируют внутренний адрес.
- Странные схемы:
file://,gopher://и другие неожиданные схемы.
Как защищаться, если вы строите эту функцию
SSRF предотвращается в «том, как вы строите функцию». Это правила, которые этот сайт накладывает на собственные диагностические функции.
Используйте allowlist для назначений
Ограничьте схему (http/https) и хост только разрешённым набором. «Разрешить только эти» прочнее, чем «блокировать внутренние».
Блокируйте внутренние цели
Запретите достижимость 127.0.0.1 / 10.x / 192.168.x / 169.254.169.254 (метаданные).
Только домены, которыми владеет пользователь (для диагностики)
Ограничьтесь доменами, владение которыми пользователь доказал. Не давайте им целиться в сторонние сайты.
Закройте бреши и защитите метаданные
Валидируйте конечную цель редиректа, учитывайте DNS rebinding и требуйте метаданные на основе токена (например, IMDSv2) в облаке.
Этот сайт строится на принципах «не хранить секретов», «диагностировать только доказанно-собственное» и «минимизировать радиус поражения» (→ Об этом сайте).
Читать дальше
- Глоссарий: Что такое RCE · Что такое CVE
- Основы: Основы безопасности
- Защита: Подделка X-Forwarded-For и доверенные прокси
FAQ
QУ каких функций обычно бывает SSRF?
Функции, где «сервер загружает URL от пользователя»: генерация OG/превью ссылок, доставка вебхуков, импорт изображений, диагностика сайтов. Чем удобнее функция, тем больше осторожности она требует.
QПочему SSRF особенно опасен в облаке?
У облачных ВМ есть «эндпоинт метаданных» только для внутреннего доступа, который может выдать временные учётные данные. Если SSRF до него дотянется, эти ключи крадут, и атака цепляется к массовому выносу хранилища (путь утечки Capital One).
QКак защититься от SSRF?
Строго валидируйте назначения через allowlist и блокируйте достижимость внутренних IP (127.0.0.1, 10.x, метаданные 169.254.169.254). Для диагностики ограничьтесь доменами, которыми пользователь доказал владение, и закройте бреши следования за редиректами и DNS-rebinding.