Bug2Lab — CSRF: изменение данных без токена защиты

CSRF: изменение данных без токена защиты

В приложении отключена CSRF-защита. Злоумышленник может заставить уже залогиненного пользователя (у которого есть сессия/куки) выполнить POST-запрос на изменение почты/пароля, просто подсовывая скрытую форму.

Как выглядит атака

Жертва заходит на злой сайт. Там автопост форма: POST /user/email/update от имени жертвы (куки сессии прилагаются браузером автоматически).

Hidden form auto-submitted to /user/email/update

newEmail=hacker@evil.example
passwordConfirm=123456

Сервер отвечает 200 OK. Почта жертвы изменена.

Почему это стало возможным

В конфигурации Spring Security CSRF был отключён «чтоб не мешало фронту». Значит сервер не проверяет, что запрос пришёл именно с нашего сайта.

Проблемный код
@Bean
SecurityFilterChain filter(HttpSecurity http) throws Exception {
    http
        .csrf(csrf -> csrf.disable()) // ❌ CSRF отключён
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated());
    return http.build();
}

Как это чинится правильно

Включаем CSRF и требуем csrf-токен во всех state-changing запросах (POST/PUT/DELETE). Браузер атакующего такой токен не знает → запрос блокируется.

Исправленный паттерн
@Bean
SecurityFilterChain filter(HttpSecurity http) throws Exception {
    http
        .csrf(csrf -> csrf.enable()) // ✅ включено
        .authorizeHttpRequests(auth -> auth.anyRequest().authenticated());
    return http.build();
}

bug2regressРегрессионный тест

Тест шлёт POST без csrf-токена. Если сервер всё ещё отвечает 200 — стопаем билд. Ожидаем 403.

#!/bin/bash # csrf-check.sh STATUS=$(curl -s -o /tmp/resp.json -w "%{http_code}" \ -X POST \ -b "SESSION=fake-user-session-cookie" \ -d "newEmail=hacker@evil.example" \ https://staging.example.internal/user/email/update) if [ "$STATUS" = "200" ]; then echo "[BLOCK] CSRF: можно менять данные без CSRF-токена" exit 1 fi echo "[OK] Сервер требует CSRF-токен (HTTP $STATUS)" exit 0

Это делает невозможной тихую подмену пользовательских настроек через внешние сайты.

Проверка пониманияЧто было не так?

CSRF был отключён, и сервер принимал POST-запросы без защиты.

Атакующий мог менять данные пользователя через скрытую форму на другом сайте.

Фикс — включить CSRF и требовать валидный токен.

Проблема была только в отсутствии HTTPS.

Стандарт:любые state-changing запросы требуют CSRF-токен. Отключать CSRF «чтобы не мешал фронту» нельзя.

Теория (по желанию) CSRF = «мы заставили пользователя нажать кнопку, не спрашивая его»

🎯1. Что такое CSRF?

Cross-Site Request Forgery = когда злоумышленник заставляет браузер жертвы сделать POST/PUT/DELETE-запрос на ваш сайт, используя её же сессию. С точки зрения вашего бэкенда это выглядит как «сам пользователь поменял себе почту».

💼2. Почему бизнесу больно?

Смена контактной почты → перехват аккаунта.
Смена банковских реквизитов для выплат.
Отключение 2FA «по просьбе пользователя».

Пользователь потом говорит: «Это сделали через ваш официальный кабинет, я тут ни при чём» — и юридически это ад.

🧪3. Почему у вас это было отключено?

«Фронту мешает токен, отключим CSRF пока».
«Это внутренняя админка, не критично» → потом её подключили к продуктиву.
«Микросервис же за API-gateway, никто не достанет» → всё равно достали.

То есть это такой «временный хак», который живёт годами.

📏4. Новый стандарт

CSRF не отключаем ради удобства.
Если у нас чистый API без браузерной сессии — ок, но если есть куки-сессия, нужен CSRF-токен.
Любой новый POST/PUT/DELETE с куками должен требовать токен.

Это не «безопасники хотят», это «иначе аккаунты угонят через фрейм на чужом сайте».

🚦5. Регресс в пайплайне

Автотест пытается сделать POST без токена. Если получилось — билд падает. Значит, это уже под контролем, а не «ну мы договорились не выключать CSRF».

bug2regressРегрессионный тест

Проверка пониманияЧто было не так?

Теория (по желанию) CSRF = «мы заставили пользователя нажать кнопку, не спрашивая его» раскрыть

Теория (по желанию) CSRF = «мы заставили пользователя нажать кнопку, не спрашивая его»