Подделка серверных запросов SSRF относится к числу опасных уязвимостей веб приложений. Суть SSRF в том что злоумышленник заставляет сервер выполнять сетевые обращения от своего имени к внутренним сервисам инфраструктуры. В итоге атакующий получает доступ к ресурсам которые напрямую из интернета недоступны, что открывает путь к обходу аутентификации, чтению конфиденциальных данных и дальнейшей эскалации атак внутрь сетевого периметра.
Причина SSRF заключается в передаче неконтролируемых пользовательских данных в функции сетевых запросов. Когда приложение доверяет параметрам URL адресам и хостам без строгой проверки. Чтобы защищаться, важно понимать как возникает уязвимость, какие бывают сценарии эксплуатации и как их выявлять на практике.
Виды SSRF и типовые сценарии
Чаще всего встречается сценарий когда в параметр url feed redirect download или аналогичный пользователь передает произвольный адрес, а сервер по этому адресу скачивает файл, делает HTTP запрос или открывает TCP соединение. Если проверка ограничивается только формальным форматом URL атакующий может указать внутренний ресурс например http://127.0.0.1/admin http://10.0.0.5:8080 или адрес метаданных облака по типу http://169.254.169.254/metadata.
Отдельно выделяют blind SSRF когда ответ внутреннего сервиса не отображается пользователю напрямую. Результат атаки оценивают по побочным эффектам по времени ответа ошибкам в логах внешним колбекам на контролируемый хост. Blind сценарии удобны для сканирования внутренней сети и подбора открытых служб даже при ограниченном сетевом интерфейсе приложения.
Дополнительную опасность создают нестандартные схемы и протоколы. Если приложение передает данные в универсальный клиент без ограничения схемы атакующий может использовать схемы file gopher dict или специальные адаптеры библиотек, что позволяет выходить за рамки обычного HTTP запроса и взаимодействовать с базами данных очередями сообщений и другими компонентами внутренней инфраструктуры.
Инструменты и практические приемы обнаружения
Практический поиск уязвимостей SSRF почти всегда опирается на связку прокси анализаторов браузера специализированных фреймворков и качественных словарей полезных нагрузок. Ниже разберем типовой рабочий процесс и то как конкретные инструменты помогают двигаться от гипотезы к подтвержденной уязвимости.
Прокси как центральная точка анализа. Базовым инструментом остается перехватывающий прокси по типу Burp Suite или OWASP ZAP. Настраиваем браузер на использование прокси на 127.0.0.1:8080 проходим по приложению в обычном режиме и собираем историю HTTP запросов. Далее фильтруем ее по параметрам которые потенциально содержат адреса ресурсов например url redirect uri path next callback dest. Такой подход широко используется в практических руководствах по охоте на SSRF, поскольку именно эти параметры чаще всего оказываются точками входа.
После выделения кандидатов запросы с интересующими параметрами отправляются в модуль Repeater в Burp или аналог в ZAP. Дальше начинается ручное тестирование в виде последовательной подстановки разных адресов. Сначала применяют безопасные варианты из внешних словарей и собственного списка например http://127.0.0.1:80, http://localhost, http://10.0.0.1:8080/health, http://169.254.169.254/latest/meta-data/ и наблюдают как меняется ответ и время обработки запроса.
Использование OWASP ZAP в режиме сканера. Для ускорения начального этапа можно запустить ZAP в контейнере в режиме базового сканера по целевому хосту и получить отчет о подозрительных параметрах которые в дальнейшем будут до исследованы вручную. Пример запуска:
docker run -u zap -p 8080:8080 owasp/zap2-docker-stable \
zap-baseline.py -t https://target.example -r zap-ssrf-report.html
Отчет не заменяет ручного тестирования, но помогает быстро найти места, где пользовательский ввод влияет на сетевое поведение приложения например триггерит обращение к внешнему URL или загрузку контента для предпросмотра.
SSRFmap как специализированный фреймворк. После того как найдена точка возможного SSRF удобно передать ее в автоматизированный инструмент SSRFmap который был разработан специально для фаззинга и эксплуатации такого класса уязвимостей. SSRFmap принимает на вход сохраненный файл HTTP запроса из Burp и имя параметра который нужно фаззить, а далее подставляет в него заранее подготовленные полезные нагрузки и запускает набор модулей эксплуатации.
Установка фреймворка в систему типична и ставиться как обычное Python приложение:
git clone https://github.com/swisskyrepo/SSRFmap.git
cd SSRFmap
pip install -r requirements.txt
Далее формируем файл запроса например data/request.txt экспортируя его из Burp и указывая в нем реальный рабочий запрос к эндпоинту с параметром url. Базовый запуск может выглядеть так
python ssrfmap.py -r data/request.txt -p url -m readfiles,portscan
В этом режиме SSRFmap сначала пытается прочитать типовые файлы вроде /etc/passwd а затем использует уязвимый параметр для сканирования портов на целевом хосте. Модули перечисляются через -m и могут включать не только чтение файлов и сканирование, но и взаимодействие с конкретными сервисами например redis, mysql, docker что позволяет автоматически строить цепочки атаки через SSRF к внутренним службам.
Для более агрессивного тестирования можно задать ключ --level который включает более изощренные полезные нагрузки например использование IPv6 представления адресов или различных форм URL кодирования. Рекомендованная практика начинать с минимального уровня и ограниченного набора модулей чтобы не создавать лишней нагрузки на инфраструктуру и не инициировать необратимые действия во внутренних сервисах.
Автоматизация поиска скрытых параметров. Помимо явных параметров некоторые SSRF реализуются через скрытые поля форм или нестандартные имена переменных. В дистрибутивах по типу BlackArch доступны утилиты вроде lorsrf и других сканеров которые перебирают большой словарь имен параметров и пытаются выявить те которые приводят к загрузке внешних ресурсов или заметным сетевым эффектам. На практике их имеет смысл применять после ручного знакомства с приложением, чтобы сфокусировать перебор на конкретных эндпоинтах и тем самым снизить шум в логах.
Инструменты для Blind SSRF. Для подтверждения слепых уязвимостей удобно использовать внешние сервисы приема HTTP и DNS запросов по типу Burp Collaborator или отдельных утилит которые поднимают небольшой сервер логирования на стороне исследователя. Идея проста параметр приложения заполняется уникальным доменным именем, а все входящие обращения к нему фиксируются уже вне целевой инфраструктуры, что позволяет надежно отличить реальные SSRF запросы от ложных срабатываний.
Примечание о словарях и лучших практиках. Эффективность инструментов сильно зависит от качества словарей. Наиболее распространенным источником является проект SecLists который предоставляет коллекции словарей для разных задач, в том числе списки потенциальных параметров и полезных нагрузок для SSRF и других веб атак. Репозиторий можно установить через пакетный менеджер в Kali Linux
sudo apt install seclists
# словари будут доступны в /usr/share/seclists
или клонировать напрямую
git clone --depth 1 https://github.com/danielmiessler/SecLists.git
Для SSRF обычно используют две группы словарей. Во-первых, списки имен параметров, чтобы находить скрытые точки ввода. Во-вторых, наборы полезных нагрузок с внутренними адресами облачными метаданными альтернативными формами записи localhost и типовыми путями к диагностическим и конфигурационным ресурсам.
Лучшие практики рекомендуют начинать с небольших целевых словарей подбирая наборы адресов под конкретную инфраструктуру мониторить логи и отклик приложения во время фаззинга и комбинировать автоматический перебор с осмысленным ручным анализом вместо бездумного запуска тысяч запросов. Такой подход делает использование инструментов вроде SSRFmap и вспомогательных сканеров более точным и управляемым, что особенно важно в боевых средах.
