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

# SSRF: запрос к внутреннему эндпоинту через серверный клиент ## Сценарий Вы аудируете **PixelPort** — маркетплейс цифрового контента на Go. В профиле пользователя есть функция «загрузить аватар по ссылке»: вы указываете URL изображения, сервер сам скачивает его и сохраняет. Команда считает эндпоинт безобидным прокси для внешних картинок. По данным внутреннего аудита, в приложении есть служебный эндпоинт статистики, доступный только с loopback-адреса самого сервера: проверка доверяет адресу источника запроса, а в ответе содержится флаг. Задача — добраться до него, имея лишь обычную учётную запись. ## Цель 1. Изучите поведение функции загрузки аватара: какой URL принимает сервер и куда фактически уходит запрос. 2. Заставьте сервер обратиться к служебному эндпоинту самого себя — исходящий запрос будет идти от лица приложения и пройдёт проверку источника. 3. Извлеките флаг из ответа служебного эндпоинта. ## Теория **SSRF (Server-Side Request Forgery)** — атакующий заставляет сервер выполнить HTTP-запрос по выбранному им адресу. Запрос исходит от сервера и наследует его сетевые привилегии: проходит периметр, видит внутренние сервисы, обращается к самому приложению через loopback. Эндпоинты, «защищённые» проверкой адреса источника, против SSRF бессильны: источником и есть сам сервер. **Уязвимый паттерн:** ```go // Запрос по пользовательскому URL без проверки адреса назначения avatarURL := r.FormValue("avatar_url") resp, err := http.Get(avatarURL) ``` Многие внутренние интерфейсы доверяют сетевой границе — «доступно только с localhost». SSRF обходит эту границу изнутри: достаточно указать адрес самого приложения и порт, на котором оно слушает. ## Точка входа атаки `POST /fetch-avatar` — функция загрузки аватара по ссылке в профиле; поле `avatar_url` (форма защищена CSRF-токеном). * **Обычный пользователь:** `demo` / `demo` * **Цель:** служебный эндпоинт статистики, доступный только с loopback-адреса сервера; его ответ содержит флаг