CSRF: SameSite=Lax обходится через GET (Express)

# CSRF: обход SameSite=Lax через GET-запрос ## Сценарий Кофейня **«Дедлайн-Кафетерий»** продаёт кофе и мерч через магазин на Express, и safety-инженер открыл тикет: страница профиля умеет менять email переходом по ссылке, а вся защита от CSRF — атрибут SameSite на сессионном cookie. Разработчик уверен, что современный браузер сам разорвёт любую межсайтовую атаку. Ваша задача — проверить, так ли это для каждого чувствительного действия в приложении. ## Цель 1. Войдите как обычный пользователь и изучите смену email: каким методом работает эндпоинт и как передаётся новый адрес. 2. Определите, для какого типа переходов политика SameSite=Lax всё же отправляет cookie, и соберите страницу-ловушку на сервере эксплойтов. 3. Отправьте ловушку администратору через механизм отчётов и дождитесь смены его email. 4. Заберите флаг из каталога: после смены email администратора карточка товара **CTF Flag** раскрывает его. ## Теория SameSite=Lax блокирует cookie в межсайтовых запросах, но делает исключение для GET-навигации верхнего уровня: обычный переход по ссылке открывает адрес с cookie сессии. Если смена состояния реализована GET-запросом с параметрами в адресе, это исключение превращается в полноценную CSRF-уязвимость. **Уязвимый паттерн:** ```js // изменяющее состояние действие выполнено GET-запросом app.get('/api/email/change', (req, res) => { /* запись в базу */ }); ``` Злоумышленник размещает страницу, которая при открытии выполняет переход верхнего уровня на адрес смены email с подставленным значением. Жертва открывает страницу, браузер прикладывает cookie — и сервер меняет email от имени жертвы. Никакого токена и проверки источника в обработчике нет. ## Точка входа атаки `GET /api/email/change` — параметр `email`; страница-ловушка размещается на сервере эксплойтов и доставляется жертве через `POST /report`. * **Тестовый пользователь:** `demo` / `demo` * **Жертва:** администратор (открывает ссылку из отчёта)