SSRF: Redirect Bypass

# SSRF: обход фильтра через перенаправление ## Сценарий «Вектограм» — студия-магазин печатной графики: у мастеров профили, аватар можно загрузить по ссылке, и сервер сам скачивает картинку. После нашумевшей истории с утечкой через чужие аватары разработчик поставил фильтр адресов и успокоился. Владелец студии нанял вас проверить защиту до запуска новой линейки — и вас интересует не только что фильтр проверяет, но и чего он не замечает. ## Цель 1. Войдите покупателем и убедитесь, что прямая ссылка на внутренние адреса в форме загрузки аватара блокируется фильтром. 2. Найдите две слабости: кому фильтр доверяет без проверки адреса и какое стандартное поведение HTTP-клиента он не учитывает. 3. Выстройте цепочку из перенаправления: «безопасный» начальный адрес, ведущий внутренним эндпоинтом статистики, и получите флаг из ответа. ## Теория Проверка адреса перед запросом защищает ровно одно подключение — первое. HTTP-запрос — это цепочка шагов: сервер может ответить перенаправлением на любой другой адрес, а HTTP-клиент по умолчанию молча идёт за ним, ничего не перепроверяя. **Уязвимый паттерн:** ```python if not is_ip_safe(host): return 'Access Denied: Cannot access internal addresses', 403 resp = http_requests.get(url, timeout=5) ``` Вторая слабость — «удобство для разработки»: список доверенных внутренних имён, освобождённых от проверки адреса. Типичный корпоративный паттерн. Если доверенный сервис умеет перенаправлять туда, куда попросили, — достаточно подать его адрес с параметром-целью: фильтр пропустит первый шаг, а за перенаправлением клиент сам пойдёт к внутреннему эндпоинту уже без всякой проверки. ## Точка входа атаки `POST /profile/fetch-avatar` — форма на странице профиля, поле `url` (потребуется вход и токен формы со страницы профиля). * **Обычный пользователь:** `demo` / `demo`