CSRF: межсайтовая подделка запроса

CSRF (Cross-Site Request Forgery, межсайтовая подделка запроса) — атака, при которой браузер жертвы выполняет нежелательное действие на сайте, где жертва уже авторизована, не потому что жертва сама на это согласилась, а потому что сторонняя страница или ссылка незаметно инициировала запрос от её имени. Сайт-жертва видит обычный запрос от залогиненного пользователя — с валидными куки сессии — и выполняет его, не зная, что инициатором был не сам пользователь, а чужая страница.

CSRF часто путают с XSS (межсайтовым скриптингом), потому что обе атаки эксплуатируют веб-приложение через браузер жертвы, но механика разная. XSS внедряет вредоносный JavaScript-код в саму страницу и выполняет его в браузере жертвы — с доступом к содержимому страницы, куки и вводимым данным. CSRF ничего не внедряет в атакуемый сайт и не выполняет там свой код — он заставляет браузер жертвы отправить запрос, ответ которого атакующий даже не видит; отсюда и «вслепую» в описании атаки.

Таблица ниже сводит основные различия по пяти признакам.

↔ таблицу можно прокрутить вбок

Механика CSRF строится на том, что браузер автоматически прикладывает cookie сессии к любому запросу на сайт, для которого эта cookie выставлена — независимо от того, с какой страницы запрос был инициирован. Атакующему не нужно красть эту cookie, ему достаточно заставить браузер жертвы отправить запрос, а куки браузер приложит сам.

Типичный сценарий: жертва авторизована в банковском или другом веб-приложении с cookie-сессией, затем открывает стороннюю страницу — например, по ссылке из письма. На этой странице размещён код, который автоматически инициирует запрос к атакуемому сайту: скрытая форма, автоматически отправляющая себя при загрузке страницы, или тег <img src="...">, указывающий на URL с параметрами изменяющего действия, если это действие выполняется GET-запросом.

Браузер жертвы отправляет запрос вместе с валидными куки сессии — сайт обрабатывает его как легитимный.

Классические цели такой атаки — действия, которые меняют состояние аккаунта или данные: перевод денег со счёта, смена пароля или email, привязанного к аккаунту, изменение адреса доставки, добавление нового получателя платежа. Атакующий не видит результат и не может прочитать ответ сервера — но само выполнение действия от имени жертвы уже даёт результат: деньги переведены, email заменён на контролируемый атакующим, дальнейшее восстановление доступа переходит к нему.

Основная защита от CSRF находится на стороне приложения и браузера одновременно — сервер проверяет уникальное значение при каждом изменяющем запросе, а браузер по умолчанию ограничивает отправку cookie при межсайтовых переходах. Средства сетевой защиты дополняют это, но не заменяют.

Web Application Firewall дополняет эти меры на уровне сетевого трафика: класс WAF может отслеживать аномальные запросы без ожидаемых заголовков или токенов, но не заменяет проверку CSRF-токена в коде приложения — это по-прежнему основной рубеж. Для веб-приложений, где изменяющие действия выполняются через API, та же логика проверки происхождения запроса и токена переносится на уровень API-эндпоинтов — эту область закрывает класс API Security.

В актуальной версии OWASP Top 10 CSRF не выделен отдельной категорией — он входил в список как отдельный риск A8 в редакции OWASP Top 10 2013 года, но был исключён при обновлении 2017 года. Причина — рост числа веб-фреймворков, которые встраивают защиту от CSRF по умолчанию, из-за чего доля уязвимых приложений в собранных для рейтинга данных заметно снизилась.

Это не означает, что атака полностью исчезла: риск остаётся там, где разработчик отключил встроенную защиту фреймворка, не выставил атрибут SameSite явно или использует нестандартную схему аутентификации, не покрытую защитой фреймворка по умолчанию. Полный разбор актуальных категорий риска — на профильной странице словаря OWASP Top 10, где также описано, как рейтинг применяют для приоритизации задач в проекте безопасной разработки.