CSRF: Обход проверки Referer (Flask)

# CSRF: обход проверки заголовка Referer ## Сценарий Перед вами интернет-магазин SecureShop. Команда разработки знает про класс уязвимостей CSRF и **попыталась защитить** один из чувствительных эндпоинтов — изменение адреса электронной почты. Однако защита реализована не через стандартный механизм CSRF-токенов, а через проверку заголовка `Referer` HTTP-запроса. Это типичная попытка «лёгкой» защиты, которая в большинстве случаев ломается при первом же эмпирическом изучении. В системе есть административный аккаунт. Если злоумышленнику удастся через CSRF поменять привязанный к этому аккаунту email, то служебное уведомление о смене email уйдёт **владельцу нового email-адреса** — а в письме, по «удивительному совпадению», лежит CTF-флаг. Это значит: если в payload подставить email, который контролирует атакующий, флаг придёт ему в почтовый клиент приложения (`/email`). Ваша задача — найти изъян в реализации Referer-проверки, провести CSRF-атаку, обходящую её, и подставить такой адрес, к которому у вас есть доступ. ## Цели 1. Авторизуйтесь как `demo` / `demo`, найдите в личном кабинете форму изменения email и определите, как именно сервер пытается защитить её от CSRF. 2. Эмпирически найдите способ обойти эту защиту — как сделать так, чтобы запрос со стороннего домена выглядел для сервера «правильным». 3. Подготовьте exploit-страницу и доставьте её администратору через предусмотренный для этого механизм отчётов. 4. После того как email админа сменится на адрес, который вы контролируете (например, email пользователя `demo`), откройте `/email` под этим пользователем и заберите CTF-флаг из служебного уведомления. ## Данные | Параметр | Значение | |----------|----------| | Тестовый пользователь | `demo` / `demo` | | Цель атаки | смена email пользователя `admin` на адрес, к которому у атакующего есть доступ (например, `demo@secureshop.local` — email пользователя `demo`) |