CSRF: токены и SameSite

CSRF заставляет браузер жертвы выполнить нежелательное действие на сайте, где она уже авторизована.

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

Хитрость CSRF в том, что браузер автоматически прикладывает cookie сессии к любому запросу на сайт — даже если запрос инициирован с чужой страницы. Сервер видит валидную сессию и думает, что действие осознанное.

Как возникает атака

Пользователь авторизован на банковском сайте. Открыв другую вредоносную страницу, его браузер незаметно отправляет на банк запрос (например, форму перевода), и cookie сессии прикладывается автоматически. Без защиты сервер выполнит перевод. Мы описываем механику, а не даём готовую страницу-атаку.

Защита: CSRF-токены

Классическое решение — CSRF-токен: при отрисовке формы сервер кладёт в неё уникальный непредсказуемый токен и запоминает его для сессии. При отправке формы токен возвращается, и сервер сверяет. Чужая страница токен не знает, поэтому подделать запрос не может.

<form method="POST" action="/perevod">
  <input type="hidden" name="csrf_token" value="уникальный_токен">
  <input name="summa">
</form>

Защита: SameSite-cookie

Атрибут SameSite у cookie указывает браузеру, прикладывать ли её к межсайтовым запросам.

Значение	Поведение
Strict	cookie не отправляется при любых переходах с других сайтов
Lax	отправляется только при обычной навигации (переход по ссылке), не при фоновых POST
None	отправляется всегда (требует Secure) — самый слабый вариант

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax

Как защищаться

Используйте CSRF-токены для всех изменяющих состояние запросов (POST, PUT, DELETE).
Ставьте cookie сессии атрибут SameSite (Lax как разумный дефолт, Strict где можно).
Проверяйте, что небезопасные действия выполняются только методами, изменяющими состояние, а не GET.
Для API на токенах в заголовке (а не в cookie) CSRF менее актуален, но проверяйте схему аутентификации.

Частые ошибки разработчиков

Выполняют изменяющие действия по GET-запросу (например, удаление по ссылке) — лёгкая мишень для CSRF.
Полностью отключают встроенную CSRF-защиту фреймворка «чтобы не мешала».
Полагаются только на проверку заголовка Referer, который не всегда надёжен.

Итог

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