CSRF — межсайтовая подделка запроса¶
CSRF (от англ. Cross-Site Request Forgery, также известен как XSRF или «межсайтовая подделка запроса») — тип атаки на веб-приложения, при которой злоумышленник подменяет действия аутентифицированного пользователя, заставляя его браузер выполнить нежелательный HTTP-запрос к сайту, где пользователь уже авторизован. Атака использует доверие сервера к сессионным данным (cookie, HTTP-аутентификация), которые браузер отправляет автоматически. CSRF относится к классу атак типа «человек посередине» и «подделка запроса» и входит в список наиболее распространённых уязвимостей веб-приложений по классификации OWASP.
¶Принцип работы
Предположим, пользователь авторизован на банковском сайте и его браузер хранит сессионную cookie. Если пользователь в это же время посещает вредоносную страницу, содержащую скрытый HTML-форму или JavaScript-код, отправляющий запрос к банковскому API (например, POST /transfer?to=attacker&sum=100000), браузер автоматически приложит к этому запросу валидную сессионную cookie. Сервер, получивший запрос, не может отличить его от запроса, инициированного самим пользователем, и выполнит перевод средств.
Ключевые условия успешности CSRF:
- пользователь аутентифицирован на целевом сайте;
- браузер автоматически отправляет учётные данные (cookie, HTTP Basic/дайджест-аутентификация);
- приложение не применяет дополнительные механизмы защиты от подделки запроса.
Атака не требует доступа к содержимому cookie — достаточно, чтобы браузер пользователя сам их отправил. Это отличает CSRF от атаки XSS, при которой злоумышленник получает прямой доступ к данным страницы.
¶Способы атаки
Запрос, инициируемый через CSRF, может быть выполнен разными способами:
- Скрытые HTML-формы — на вредоносной странице размещается
<form method="POST" action="https://victim.com/api"><script>document.forms[0].submit()</script>`.со скрытыми полями и автоматической отправкой через - Изображения и ссылки — теги
<img src="https://victim.com/delete?id=1"><a href>` вызывают GET-запросы. Если приложение использует GET для изменяющих состояние операций, атака упрощается.или - JavaScript через XMLHttpRequest/fetch — при отсутствии защитных заголовков CORS или SameSite браузер может отправить запрос с cookie к другому origin.
- CSS и другие векторы — исторически использовались для автоматической подгрузки ресурсов.
GET-запросы, изменяющие состояние сервера, считаются нарушением принципов REST и одновременно главным фактором риска CSRF.
¶Методы защиты
¶Секретные токены (anti-CSRF tokens)
Наиболее распространённый и рекомендуемый метод. Сервер генерирует непредсказуемый токен, связанный с сессией пользователя, и включает его в каждую форму или передаёт в заголовке. При отправке формы сервер проверяет совпадение токена. Так как злоумышленник не может прочитать содержимое страницы целевого сайта (это запрещено политикой same-origin), он не сможет подставить корректный токен.
Реализации: синхронные токены (скрытое поле формы), заголовки X-CSRF-Token, двойная подпись cookie (double-submit cookie).
¶Заголовок SameSite
Браузеры поддерживают атрибут SameSite для cookie:
SameSite=Strict— cookie не отправляется при межсайтовых запросах;SameSite=Lax— cookie отправляется только при навигационных GET-запросах (переход по ссылке), но не при POST из чужого origin;SameSite=None— cookie отправляется всегда (требуетSecure).
Атрибут Lax по умолчанию во всех современных браузерах с 2020 года, что существенно снизило актуальность классических CSRF-атак, однако не устраняет их полностью (в частности, для устаревших браузеров и некоторых сценариев).
¶Проверка заголовка Origin / Referer
Сервер может отклонять запросы, у которых заголовок Origin или Referer указывает на чужой домен. Метод прост, но имеет ограничения: заголовки могут отсутствовать (политика приватности, некоторые прокси) или подделываться в старых браузерах.
¶Дополнительные меры
- отсутствие state-changing операций через GET;
- применение CORS с запретом кросс-доменных запросов с учётными данными;
- требование повторной аутентификации для критических операций (смена пароля, перевод средств).
¶История и значимость
Термин «Cross-Site Request Forgery» был введён в 2001 году исследователем Jeremiah Grossman. В 2007 году CSRF был включён в список OWASP Top Ten и с тех пор остаётся одной из ключевых категорий уязвимостей веб-приложений. Известные инциденты: атаки на сервисы Netflix, YouTube (2008), банковские системы ряда стран.
В 2020-е годы, с массовым внедрением SameSite=Lax по умолчанию, частота классических CSRF-атак снизилась, однако метод остаётся актуальным для приложений, использующих устаревшие библиотеки, кастомные схемы аутентификации или нестандартные API.
¶Источники
- OWASP — Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet
- OWASP Top Ten (2021)
- RFC 3546, RFC 6265 (HTTP State Management Mechanism)
- Jeremiah Grossman, «Cross-Site Request Forgery» (2001)
- MDN Web Docs — SameSite cookies