[securitylab::pro]
// Безопасность / Веб

SSRF: подделка запросов на стороне сервера

2026.08.23  //  Редакция  //  00:26
SSRF — подделка запросов на стороне сервера

SSRF (Server-Side Request Forgery) — уязвимость, при которой атакующий заставляет ваш сервер отправить запрос по произвольному адресу. Запрос идёт изнутри периметра и достаёт то, что снаружи недоступно: внутренние сервисы, облачные метаданные, локальные порты. SSRF получил отдельное место в OWASP Top 10 2021 (A10) — редкая честь для одного класса уязвимости. И не зря: именно SSRF стоит за одними из крупнейших взломов десятилетия.

Проверьте свой сайт на эти уязвимости

Мы вручную протестируем ваше веб-приложение по методологии OWASP и покажем, какие из описанных рисков реально эксплуатируются, с доказательствами и планом устранения.

Заказать пентест веб-приложений → или обсудить пентест

Взломы, которые сделал SSRF

  • Capital One (2019): через SSRF в приложении на AWS атакующий дошёл до сервиса метаданных 169.254.169.254, получил временные IAM-ключи и выгрузил ~100 млн записей клиентов из S3. Итогом стал штраф $80 млн. Каноничный пример.
  • MS Exchange ProxyLogon (CVE-2021-26855, 2021) — SSRF в Exchange, с которого началась цепочка до RCE. Массовая эксплуатация: десятки тысяч серверов по миру за недели. SSRF как точка входа в полный захват.

Как работает атака

Любая функция, которая ходит по URL от пользователя, это потенциальный SSRF. Загрузка картинки по ссылке, вебхук, генератор PDF/превью, импорт, проверка ссылки:

POST /api/avatar/from-url
{ "url": "https://i.imgur.com/cat.png" }         # задумано так

# атака: облачные метаданные AWS ↓
{ "url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/" }
# сервер сам сходит туда и вернёт временные ключи доступа

Точки метаданных для запоминания (их первыми пробуют атакующие):

AWS   : http://169.254.169.254/latest/meta-data/
GCP   : http://metadata.google.internal/computeMetadata/v1/  (нужен заголовок Metadata-Flavor)
Azure : http://169.254.169.254/metadata/instance?api-version=2021-02-01  (заголовок Metadata:true)

Виды SSRF

  • Basic (с ответом): ответ внутреннего запроса возвращается атакующему.
  • Blind (слепой): ответ не виден, но факт запроса подтверждается через свой сервер (Burp Collaborator / interactsh) — полезно для сканирования и эксплуатации по времени.
  • Через нестандартные схемы: gopher://, dict://, file:// — позволяют слать произвольные пакеты внутренним сервисам (Redis, SMTP) и читать файлы.
  • DNS rebinding: обход allow-list подменой DNS-ответа между проверкой и запросом (TOCTOU).
# пример эксплуатации внутреннего Redis через gopher (запись ключа/RCE)
gopher://127.0.0.1:6379/_SET%20mykey%20%22payload%22%0D%0A...

Что достаёт атакующий

  • Облачные ключи через метаданные (главный приз, как в Capital One).
  • Внутренние сервисы без аутентификации: админки, Redis, Elasticsearch, k8s API.
  • Сканирование внутренней сети и портов (по времени/коду ответа).
  • Чтение локальных файлов через file://.
  • Цепочку до RCE (как ProxyLogon).

Как защититься от SSRF: белый список адресов и рабочие меры

  1. Allow-list адресов назначения — разрешать только заранее известные хосты. Единственная по-настоящему надёжная мера.
  2. Запрет приватных диапазонов (127/8, 10/8, 172.16/12, 192.168/16, 169.254/16) — и проверка адреса после резолва DNS (против rebinding).
  3. Только http/https, запрет gopher/dict/file.
  4. IMDSv2 в AWS: требует токен-сессию, что резко усложняет кражу метаданных через SSRF (прямой урок Capital One).
  5. Отдельная сеть/прокси для исходящих запросов приложения; не возвращать сырой ответ пользователю.
// концепт серверной проверки
const ip = await dns.resolve(new URL(userUrl).hostname);
if (isPrivate(ip) || isLinkLocal(ip)) throw new Error("blocked");   // 169.254/10/172.16/192.168
if (!["http:","https:"].includes(new URL(userUrl).protocol)) throw new Error("scheme");
// перепроверить ip НЕПОСРЕДСТВЕННО перед запросом (против TOCTOU/rebinding)

Экспертное наблюдение: SSRF почти всегда живёт в «интеграционных» функциях, написанных в спешке, импорт по ссылке, вебхуки, генераторы отчётов и превью, интеграции с внешними API. Найдя любую форму «вставьте URL», мы первым делом целимся в неё, и в облаке это часто прямой путь к ключам от всей инфраструктуры.

Как это тестируется

SSRF ищется вручную: перечисляем все места, где приложение ходит по URL, подставляем внутренние адреса, метаданные и нестандартные схемы, а для слепого — ловим обращения на контрольный сервер (Collaborator). Проверяем на пентесте веб-приложений и пентесте API; облачную часть — на аудите облачной инфраструктуры.

Может ли ваш сервер сходить во внутреннюю сеть по команде извне?

Проверим все точки, где приложение ходит по URL — включая слепой SSRF и облачные метаданные — раньше, чем это превратится в кражу ключей.

Заказать пентест →

Читайте также: Безопасность API, Аудит облачной инфраструктуры.

Профильные услуги SecurityLab: тестирование на проникновение · пентест веб-приложений · Аудит облачной безопасности.

← назад в блог