SSRF: Cloud Metadata Bypass

# SSRF: служба метаданных облака за неполным фильтром ## Сценарий «СтратоМаркет» — маркетплейс электроники, работающий в облачной инфраструктуре. В каталоге есть функция сравнения цен: покупатель подаёт ссылку на страницу другого магазина, сервер скачивает её и показывает содержимое. Разработчик знает про SSRF и поставил перед загрузкой фильтр — обращения к «локальным» адресам отвергаются. Вы — аудитор облачной безопасности: проверьте, все ли опасные направления фильтр действительно закрывает. ## Цель 1. Войдите покупателем и изучите форму загрузки внешней страницы на странице каталога. 2. Установите, какой класс адресов фильтр блокирует, и убедитесь, что остальные непубличные классы он пропускает. 3. Через форму обратитесь к службе метаданных облака по её внутреннему адресу и получите временные учётные данные роли инстанса — флаг спрятан внутри них. ## Теория Облачная виртуальная машина общается со специальной службой метаданных по внутреннему адресу, невидимому снаружи. Служба отдаёт параметры инстанса, включая временные учётные данные назначенной роли, — в нормальной модели угроз туда «никто извне не достучится». SSRF ломает это допущение: запрос выполняет сам сервер. **Уязвимый паттерн:** ```python ip = ipaddress.ip_address(sockaddr[0]) if ip.is_loopback: return False ``` Фильтр распознаёт только обращения к самому узлу, а непубличных классов адресов больше: приватные сети, канальные локальные, зарезервированные диапазоны. Внутренний адрес метаданных облака относится к другому классу — канальному локальному, — поэтому беспрепятственно проходит проверку. В лаборатории служба метаданных эмулируется, но адрес, фильтр и ответ с учётными данными выглядят ровно как в настоящем облаке. ## Точка входа атаки `POST /fetch-url` — форма сравнения цен на странице каталога, поле `url`. * **Обычный пользователь:** `demo` / `demo`