CSRF: JSON API без проверки происхождения запроса (Express)

# CSRF: атака на JSON API ## Сценарий Вы аудируете **GearFlow** — интернет-магазин на Express, чья команда недавно перевела настройки профиля с классических форм на JSON API. Разработчик уверен: новый API защищён от CSRF по самой своей природе, ведь HTML-форма не способна отправить JSON. Служба безопасности сомневается в этом аргументе и поручила вам проверку на практике. ## Цель 1. Войдите под обычным аккаунтом и изучите, как фронтенд общается с API профиля: метод, заголовки, тело. 2. Определите, какие из отправляемых клиентом атрибутов запроса сервер действительно проверяет. 3. Выполните тот же запрос с чужой страницы: добейтесь смены пароля администратора на известное вам значение через механизм отчётов. 4. Войдите под администратором и извлеките CTF-флаг из админ-панели. ## Теория Довод разработчика — лишь половина правды: браузер для cross-origin запросов с JSON-типом контента действительно выполняет preflight, который без разрешения сервера не пройдёт. Но «простые» типы контента preflight не требуют, а серверная сторона нередко распарсит JSON-тело независимо от заявленного типа. Cookie сессии браузер прикрепит к любому запросу — и API выполнит действие от имени жертвы. **Уязвимый паттерн:** ```javascript if (typeof data === 'string') { data = JSON.parse(data); // text/plain с JSON внутри — тоже принимается } if (data.password) { /* пароль обновляется без проверки намерения */ } ``` Аутентификация в обработчике есть, доказательства намерения нет: страница на чужом домене отправляет запрос с «простым» типом контента, браузер молча прикрепляет cookie администратора — и его пароль меняется. ## Точка входа атаки `POST /api/profile` — JSON API настроек профиля с полями `email`, `fullname`, `password`. Доставка страницы-приманки — Exploit Server и форма отчёта администратору. * **Обычный пользователь:** `demo` / `demo` * **Цель атаки:** `admin` (смена пароля через CSRF)