SSRF: Fetch Avatar в Express + better-sqlite3

# SSRF: подделка серверного запроса через загрузку аватара ## Сценарий Магазин одежды **«Маяк-Стайл»** включил фича-флагом «загрузку аватара по ссылке»: покупатель указывает адрес картинки, а сервер на Express скачивает её сам. Команда считает функцию безобидной — «сервер всего лишь тянет картинку», — и вас, внешнего консультанта, попросили оценить новую поверхность атаки до релиза. Каталог, заказы и админ-статистика живут в этом же приложении на SQLite. ## Цель 1. Войдите как обычный пользователь и найдите на странице профиля функцию загрузки аватара по ссылке. 2. Заставьте сервер обратиться через эту функцию к внутреннему административному эндпоинту, напрямую снаружи недоступному. 3. Извлеките флаг из ответа внутреннего сервиса, вернувшегося на страницу профиля. ## Теория SSRF (Server-Side Request Forgery) — атакующий заставляет сервер выполнить HTTP-запрос по выбранному им адресу. Запрос исходит от сервера и наследует его сетевые привилегии: loopback-интерфейс, внутренние сервисы, эндпоинты, закрытые сетевым периметром. Приложение превращается в прокси внутри доверенной зоны. **Уязвимый паттерн:** ```js // Сервер сам запрашивает адрес из формы — проверки назначения нет const url = (req.body && req.body.url) || ''; const upstream = await fetch (url); ``` Ключевая ошибка — отсутствие проверки адреса назначения до запроса. Внутренние эндпоинты часто защищены только сетевой границей («доступно только с локального интерфейса»), но при SSRF запрос приходит изнутри — от самого серверного процесса. Обработчик возвращает тело ответа в HTTP-ответ формы, поэтому содержимое внутреннего сервиса попадает к атакующему целиком. ## Точка входа атаки `POST /profile/fetch-avatar` — поля `url` и `csrf_token` (токен выдаётся на странице профиля); тело запрошенного ресурса возвращается в ответе обработчика. * **Обычный пользователь:** `demo` / `demo`