Перейти к содержимому

Поиск по платформе

SSRF через обход проверки IP с помощью HTTP-редиректа

Приложение проверяет IP адрес при первом запросе, но cURL автоматически следует редиректам на внутренние адреса — атакующий обходит проверку через промежуточный сервер.

Автор: Hack & Fix
Освоишь: allowlist URLmetadata-guard 169.254DNS-rebinding защита
Сложно+90 XP ~65 мин php
CWE-918 · A10:2021 Pro
Обложка: SSRF через обход проверки IP с помощью HTTP-редиректа Обложка: SSRF через обход проверки IP с помощью HTTP-редиректа
Задача
# SSRF: обход проверки адреса через цепочку редиректов ## Сценарий Магазин стикеров и мерча **StickerStorm** добавил предпросмотр ссылок: пользователь вводит URL, сервер скачивает содержимое и показывает превью. Разработчики знали об SSRF и построили защиту — перед запросом резолвят имя хоста в IP-адрес и блокируют loopback-диапазон. Прямое обращение к служебным эндпоинтам приложения действительно отбивается. Вас попросили проверить, нельзя ли обойти фильтр, не ломая его напрямую. ## Цель 1. Убедитесь, что прямой запрос к служебному эндпоинту приложения блокируется фильтром предпросмотра. 2. Найдите в приложении эндпоинт-«редиректор», который отвечает перенаправлением на произвольный адрес. 3. Постройте цепочку: адрес, проходящий первичную проверку, → перенаправление → внутренний адрес. 4. Извлеките флаг из ответа служебного эндпоинта. ## Теория HTTP-запрос — не одно действие, а последовательность шагов: соединение, запрос, ответ, и при статусах 3xx — новое соединение уже по адресу из заголовка перенаправления. **Redirect-based SSRF** эксплуатирует защиту, которая проверяет только первый адрес цепочки: фильтр охраняет «входную дверь», но не следит, куда ведут перенаправления. **Уязвимый паттерн:** ```php // IP-адрес проверяется один раз — до запроса $ip = gethostbyname($host); if (str_starts_with($ip, '127.')) { /* deny */ } // HTTP-клиент настроен следовать редиректам автоматически, без повторной проверки ``` Клиент, автоматически следующий за перенаправлениями, выполняет переходы сам, вне зоны контроля приложения. Атакующему достаточно «открытого редиректора» — любого доступного адреса, который возвращает 3xx на произвольный цель: так в реальном коде ведут себя партнёрские трекеры, OAuth-callback и сокращатели ссылок. Первая проверка видит безобидный адрес редиректора, а подключение после перехода выполняется уже к внутреннему эндпоинту — притом с петлевого адреса, поэтому проверки источника на том конце тоже проходят. ## Точка входа атаки `POST /fetch-url` — предпросмотр ссылок, поле `url`. * **Обычный пользователь:** `demo` / `demo` * **Цель:** служебный эндпоинт со статистикой, доступный только с loopback-адреса

Похожие лабораторные (4)

другие лабы по этой уязвимости
Обложка лабы: SSRF к облачным метаданным через обход проверки IP Обложка лабы: SSRF к облачным метаданным через обход проверки IP
SSRF

SSRF к облачным метаданным через обход проверки IP

Приложение блокирует только loopback-адреса, но не link-local 169.254.169.254 — атакующий читает облачные метаданные AWS.

+60 XP
PHP Pro
Exploit Fix
Обложка лабы: SSRF через file_get_contents() в загрузке аватара Обложка лабы: SSRF через file_get_contents() в загрузке аватара
SSRF

SSRF через file_get_contents() в загрузке аватара

Приложение загружает аватар по URL без проверки — атакующий может обратиться к внутренним сервисам.

+30 XP
PHP Pro
Exploit Fix
Обложка лабы: SSRF: Обход проверки URL через HTTP-редирект в Node.js Обложка лабы: SSRF: Обход проверки URL через HTTP-редирект в Node.js
SSRF

SSRF: Обход проверки URL через HTTP-редирект в Node.js

Админ-форма импорта продуктового фида проверяет hostname URL и отвергает loopback и приватные сети, но fetch() автоматически следует HTTP-редиректам — внешний сервер атакующего перенаправляет на внутренний /admin/stats и утечка флага.

+90 XP
Node.js Pro
Exploit Fix