CSRF: подделка межсайтовых запросов и как от неё защищаются

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

Важное отличие от XSS: злоумышленник не читает ответ и не украл токен. Он просто заставляет вас совершить действие, которое вы не собирались выполнять.

Подходят действия, меняющие состояние: смена почты или пароля, перевод, изменение настроек, публикация, удаление. Чтобы атака сработала, необходимы три условия: вы вошли на целевой сайт, действие выполняется одним запросом с предсказуемыми параметрами, а сервер не проверяет источник намерения.

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

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

С защитой картина другая. Форма содержит скрытое поле со случайным токеном, привязанным к вашему сеансу. Сервер сверяет его: чужая страница токен не видит и подставить не может, поэтому запрос отклоняется. Кроме того, если cookie помечена как SameSite Lax, браузер вообще не отправит её при скрытом межсайтовом запросе методом POST. Вместе эти меры делают атаку практически неосуществимой, если, конечно, на сайте нет XSS, который позволил бы прочитать токен.

Основной — CSRF-токен: случайное значение, которое сервер выдаёт вместе с формой и требует вернуть в запросе. Чужая страница не знает токена, поэтому подделать запрос не может. Второй — атрибут SameSite у cookie: со значением Lax или Strict браузер не отправляет cookie при межсайтовых запросах или делает это только в узких случаях. Многие браузеры сегодня по умолчанию ведут себя как при Lax, что резко сократило риск.

Дополнительно проверяют заголовки Origin и Referer, требуют повторного подтверждения для чувствительных операций и используют собственные заголовки в запросах API.

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

Если на сайте есть XSS, защита от CSRF часто теряет смысл: скрипт на странице может прочитать токен и подписать любые запросы. Поэтому меры защиты работают в комплексе.

Обратите внимание на терминологию: слово «межсайтовый» означает происхождение запроса с другого сайта, а не то, что атакуется несколько сайтов. Цель у атаки всегда один сайт, на котором у жертвы есть сеанс.

Выходите из аккаунтов после работы с чувствительными сервисами, не держите долго открытыми банковские кабинеты и почту, пока просматриваете сомнительные страницы, обновляйте браузер, чтобы работали современные настройки cookie. Двухфакторная защита не мешает CSRF-запросу от вашего имени внутри сессии, но подтверждение переводов дополнительным кодом делает атаку бесполезной.

Проверить у себя ничего специального нельзя: защита лежит на сайте. Можно лишь оценить, требует ли сервис повторного ввода пароля или кода при смене почты и реквизитов, это хороший признак.

Для API, которое используется только приложением, разумно требовать специальный заголовок или токен в теле запроса. Браузер не отправит произвольный заголовок с чужой страницы без разрешения сервера, поэтому запрос от вредоносного сайта провалится. Такая проверка проста в реализации и хорошо работает вместе с ограничением источников запросов и корректными настройками cookie.