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

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

SSRF Redirect: Обход валидации через HTTP-редирект

SSRF-уязвимость: валидация URL обходится через HTTP-редирект на внутренний адрес.

Автор: Hack & Fix
Освоишь: allowlist URLmetadata-guard 169.254DNS-rebinding защита
Средне+60 XP ~35 мин golang
CWE-918 · A10:2021 Pro
Обложка: SSRF Redirect: Обход валидации через HTTP-редирект Обложка: SSRF Redirect: Обход валидации через HTTP-редирект
Задача
# SSRF: обход валидации через HTTP-редирект ## Сценарий Вы аудируете **LinkLens** — сервис предпросмотра ссылок для маркетинговых рассылок. Пользователь передаёт URL, сервер скачивает страницу и показывает её содержимое. После прошлых инцидентов команда построила защиту: адрес назначения резолвится и проверяется по приватным диапазонам до запроса. Но ради «удобства разработки» в фильтре оставлен список доверенных внутренних имён, которые пропускаются без IP-проверки, — типичный компромисс, чтобы не плодить исключений для своих сервисов. Если доверенный сервис умеет перенаправлять на произвольный адрес, защита разваливается: проверка была выполнена до запроса, а не во время него. ## Цель 1. Подтвердите, что прямое обращение к внутреннему API через предпросмотр блокируется IP-проверкой. 2. Найдите доверенное имя, которое пропускается без проверки, и сервис за ним, отвечающий перенаправлением на произвольный адрес. 3. Постройте цепочку: первый запрос проходит валидацию, а перенаправление приводит серверный клиент к внутреннему API. Извлеките флаг из его ответа. ## Теория Защита от SSRF, выполняемая один раз **до** запроса, уязвима к смене адреса назначения **после** проверки — классический разрыв «момент проверки — момент использования». Самый частый вектор — автоматическое следование HTTP-клиента за ответами-перенаправлениями: получив ответ с адресом нового расположения, клиент молча идёт туда, не повторяя валидацию. **Уязвимый паттерн:** ```go // Проверен только начальный адрес; за перенаправлениями клиент следует сам client := &http.Client{Timeout: 5 * time.Second} resp, err := client.Get(targetURL) ``` Allowlist доверенных имён усугубляет проблему: достаточно одного перенаправляющего сервиса в доверенном списке, чтобы любой внутренний адрес стал достижим через него. ## Точка входа атаки `GET /url-preview` — параметр `url`; авторизация не требуется. * **Защищённая функция:** предпросмотр с IP-проверкой начального адреса * **Кандидат в цепочку:** доверенный helper-сервис редиректов кластера лабы — `lab-redirector.lab-infra.svc.cluster.local` * **Цель:** внутренний API приложения, доступный только с loopback-источника; его ответ содержит флаг

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

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

Bypass SSRF: Обход фильтров хоста

SSRF с обходом слабого фильтра хоста в URL и эксплуатация через альтернативные IP-адреса.

+60 XP
Go Pro
Exploit Fix
Обложка лабы: SSRF Cloud Metadata: Доступ к метаданным облака Обложка лабы: SSRF Cloud Metadata: Доступ к метаданным облака
SSRF

SSRF Cloud Metadata: Доступ к метаданным облака

SSRF-уязвимость: неполная фильтрация IP позволяет обратиться к link-local адресу облачных метаданных (169.254.169.254).

+60 XP
Go Pro
Exploit Fix
Обложка лабы: Basic SSRF: Доступ к админке Обложка лабы: Basic SSRF: Доступ к админке
SSRF

Basic SSRF: Доступ к админке

Простая SSRF-уязвимость, позволяющая получить доступ к внутренним ресурсам сервера.

+30 XP
Go Pro
Exploit Fix
Обложка лабы: SSRF к облачным метаданным через обход проверки IP Обложка лабы: SSRF к облачным метаданным через обход проверки IP
SSRF

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

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

+60 XP
PHP Pro
Exploit Fix