Обсудить проект
Обсудить проект

SSRF: от локального файла до метадаты облака

13.07.2026
77

SSRF — это когда сервер сам, добрым слогом, тащит ресурс по URL, который ты ему подсунул, вместо легитимного https://example.com/image.jpg. По OWASP A10:2021 и CWE-918 это работает на трёх фронтах: слив данных, обход контроля доступа и (если повезёт) выполнение команд. WAF тут — не стена, а приглашение на танец, если фильтр не понимает редиректы и странные схемы URL.

Точка входа: где искать дырку

Ищи любой функционал, где приложение сам ходит по URL, который ты контролируешь хотя бы частично — webhooks, генерация превью, импорт по ссылке, SSO-callback, PDF-рендеринг. Признак живой SSRF: подставляешь свой callback-сервер, ждёшь пинг — если пришёл, поздравляю, у тебя Full или Blind SSRF, зависит от того, видишь ли ответ в теле. Базовые payload’ы для разведки:

  • http://127.0.0.1/admin — локалхост-панели, о которых забыли закрыть доступ снаружи
  • http://localhost:9200/_cat/indices?v — привет, незащищённый Elasticsearch
  • file:///etc/passwd — если приложение путает файл и URL, оно радостно вернёт содержимое

Локальный файл: первый трофей

Через схему file:// можно читать всё, до чего у процесса есть права доступа: /etc/passwd, конфиги, SSH-ключи — в терминах MITRE это T1005, Data from Local System. Классический тестовый запрос выглядит так:

GET https://example.com/page?page=file:///etc/passwd

Это работает, когда параметр отдаёт содержимое напрямую в ответ, а не просто делает HTTP-запрос. Дальше — сканируем внутреннюю сеть через тот же уязвимый параметр: перебор портов на 127.0.0.1 и подсетях 192.168.x.x/10.x.x.x через Burp Intruder, группируя ответы по кодам и таймингу.

От локалхоста к облаку

Вот где начинается настоящий джекпот. Если жертва крутится в облаке, самый лакомый адрес — 169.254.169.254, link-local Instance Metadata Service, доступный без авторизации в базовой конфигурации.

Облако Эндпоинт метадаты Что забираем
AWS EC2 http://169.254.169.254/latest/meta-data/iam/security-credentials/ IAM-роль и временные access/secret ключи
Общий IMDS http://169.254.169.254/latest/meta-data/ Информация об инстансе, сети, user-data
User-data http://169.254.169.254/latest/user-data Скрипты запуска, иногда с секретами в переменных

Дальше это уже Credential Access по MITRE (T1552.005) — с украденными IAM-токенами ты не просто читаешь файлик, ты можешь дёргать AWS API от имени скомпрометированного инстанса и разгуливать по всему облачному аккаунту. Именно поэтому в 2021 SSRF внесли в OWASP Top 10 отдельным пунктом — раньше недооценивали масштаб атаки.

Обход фильтров и WAF

Если базовый payload режут — не сдавайся, это только начальный уровень пентеста. В 2026 актуальны техники DNS rebinding (домен резолвится в разное на проверке и на запросе), баги парсинга URL (http://evil.com@169.254.169.254/), редирект-цепочки (302 с внешнего сервера на metadata) и обход через альтернативные представления IP (десятичный, octal, IPv6-mapped). AWS в ответ придумали IMDSv2 с обязательным токеном через PUT-запрос — это уже не просто GET на метадату, а хоп с session token, что режет большинство наивных SSRF-цепочек.

Как это фиксить (для протокола)

Дырку лучше закрыть, чем оставить открытой для конкурентов. Базовый чек-лист защиты:

  • Разрешать только нужные схемы (http/https), рубить file://, gopher://, dict:// на входе
  • Валидировать и резолвить URL до отправки запроса, блокировать приватные и link-local диапазоны (включая 169.254.169.254)
  • Переходить на IMDSv2 в AWS и аналогичные защищённые версии метадаты в GCP/Azure
  • Сегментировать сеть, ставить firewall-правила deny-by-default для исходящих запросов приложения
  • Минимизировать IAM-права инстанса — даже если SSRF сработает, украденный токен не должен открывать всё облако