Защита от CSRF

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

Как работает атака

Пользователь авторизован на bank.ru. Злоумышленник размещает на evil.ru страницу с кодом: <img src="https://bank.ru/transfer?to=attacker&amount=1000">. Когда жертва открывает evil.ru, браузер отправляет GET-запрос на bank.ru с cookies сессии пользователя. Если bank.ru не защищён от CSRF — перевод выполняется. Для POST-запросов используются скрытые формы с <form action="bank.ru/transfer" method="POST">.

Методы защиты

• CSRF-токен — сервер генерирует уникальный непредсказуемый токен для каждой формы, помещает в скрытое поле и проверяет при POST. Злоумышленник не знает токен, не может его включить в поддельный запрос. Стандарт де-факто.
• SameSite Cookie — атрибут Set-Cookie: session=...; SameSite=Strict запрещает браузеру отправлять cookies в кросс-сайтовых запросах. SameSite=Lax (по умолчанию в Chrome с 2020 года) блокирует POST-запросы с других сайтов, но разрешает GET.
• Проверка Origin/Referer — сервер проверяет заголовок Origin или Referer входящего запроса. Если заголовок указывает на другой домен — запрос отклоняется.
• Double Submit Cookie — CSRF-токен одновременно в cookie и в теле запроса; сервер сравнивает оба значения.

История

CSRF впервые описан как атака Питером Уотерсом (Peter Waters) в 2001 году. В 2006 году Джерема Гроссман (Jeremiah Grossman) и Томас Шлейер (Thomas Schleyer) popularized атаку. OWASP включил CSRF в Top 10 с 2007 года до 2017 года (убран из-за широкого распространения SameSite защиты в браузерах). В 2020 году Chrome сделал SameSite=Lax значением по умолчанию, значительно снизив риск CSRF.

На что обращать внимание

Современные фреймворки (Laravel, Django, Rails, Express) имеют встроенную CSRF-защиту через токены. WordPress использует nonces (wp_nonce) для защиты форм и AJAX-запросов. Для REST API CSRF менее критичен при использовании stateless аутентификации (JWT в заголовке Authorization) — cookies не используются, а JWT нельзя украсть через CSRF. API с cookie-аутентификацией всё ещё уязвимы.

CSRF в веб-приложениях

CSRF (Cross-Site Request Forgery) — атака, при которой браузер жертвы отправляет запрос к целевому сайту без её ведома. Защита через CSRF-токен: уникальный случайный токен добавляется в форму и проверяется на сервере. В PHP: генерация токена $_SESSION['csrf'] = bin2hex(random_bytes(32)), проверка в обработчике формы. Фреймворки автоматически защищают от CSRF: Laravel (@csrf в Blade), Symfony (CSRF-protection компонент), Django ({% csrf_token %}). WordPress: использует wp_nonce_field() для CSRF-защиты форм плагинов. На VPS с nginx: заголовок X-Frame-Options DENY предотвращает clickjacking вместе с CSRF. SameSite cookie атрибут (Strict/Lax) — дополнительная защита: браузер не отправляет cookie при cross-site запросах. HTTPS + HSTS защищает от перехвата, но не от CSRF — нужны оба механизма. CSRF-токены хранятся в сессии пользователя (в MySQL/Redis).