CSRF: SameSite=Lax Bypass через GET-запрос (Flask)

# CSRF: обход защиты SameSite=Lax ## Сценарий Перед вами интернет-магазин SecureShop. Команда разработки знает про CSRF и **полагается** на современный встроенный механизм защиты на уровне браузера — атрибут `SameSite` на сессионном cookie. Идея понятна: если cookie не отправляется в межсайтовых запросах, то и от имени пользователя сторонний сайт ничего сделать не сможет. Однако `SameSite` имеет несколько режимов с разной строгостью, и в зависимости от того, как реализован конкретный эндпоинт (метод запроса, способ передачи параметров), эффективность защиты может варьироваться. В частности, для одного из чувствительных эндпоинтов в этой лабораторной выбранная политика `SameSite` совместно с выбранным методом HTTP **создают ровно тот сценарий, при котором cookie всё-таки прикрепляется к cross-origin запросу**. Ваша задача — обнаружить это, спроектировать exploit и провести CSRF-атаку. В системе есть административная учётная запись с CTF-флагом, доступным через специальный административный эндпоинт. Если вы сумеете подменить email админа на свой через CSRF — следующее обращение к этому эндпоинту от имени админа покажет вам флаг. ## Цели 1. Авторизуйтесь как `demo` / `demo` и изучите чувствительные эндпоинты управления профилем — каким HTTP-методом они работают, как принимают параметры. 2. Поймите, в каком режиме сервер выставляет атрибут `SameSite` сессионного cookie, и сопоставьте это с поведением браузера для разных типов cross-origin запросов. 3. Найдите тип запроса, при котором политика `SameSite` всё ещё пропускает cookie — и используйте его для CSRF-атаки на эндпоинт смены email. 4. После того как email админа сменится на ваш, заберите CTF-флаг через административный API проверки email. ## Данные | Параметр | Значение | |----------|----------| | Тестовый пользователь | `demo` / `demo` | | Цель | смена email пользователя `admin` через CSRF | ## Контекст: как работает SameSite | Тип запроса | Пример | `SameSite=Lax` | `SameSite=Strict` | |-------------|--------|---------------|-------------------| | GET-навигация верхнего уровня | `<a href>`, `window.location` | cookie отправляется | cookie блокируется | | Cross-site POST | `<form method="POST">` cross-origin | cookie блокируется | cookie блокируется | | Cross-site GET «подресурса» | `<img>`, `<iframe>`, `fetch` | cookie блокируется | cookie блокируется | Из этой таблицы видно, что `SameSite=Lax` имеет **исключение** для одного класса запросов. Именно в этом исключении и спрятана уязвимость данной лабораторной.