Как CSRF-токен предотвращает подделку запроса в веб-системе с cookie-сессией?
CSRF-токен — это непредсказуемое значение, которое сервер связывает с пользовательской сессией и требует передавать вместе с изменяющим состояние запросом. Браузер злоумышленника автоматически отправит cookie сессии, но обычно не сможет прочитать токен с другого сайта и добавить его в запрос. Сервер отклоняет запрос без корректной пары «сессия — токен».
Подход появился как ответ на особенность cookie-аутентификации: браузер автоматически прикладывает подходящие cookie к запросам, независимо от того, инициировал их пользователь через доверенный интерфейс или вредоносная страница.
Из-за этого сервер мог принять запрос от имени пользователя, хотя сам пользователь не намеревался выполнять действие. CSRF-токен добавляет в запрос секретный признак, которого нет у внешнего сайта.
Пусть пользователь вошёл в интернет-магазин, а затем открыл вредоносную страницу. Эта страница может попытаться заставить браузер отправить запрос на изменение адреса доставки или оформление заказа. Cookie сессии браузер приложит автоматически.
Если сервер проверяет только наличие действительной сессии, он не отличит легитимный запрос от подделанного. CSRF-токен решает именно эту проблему, но не защищает от компрометации самого пользовательского интерфейса или выполнения скрипта внутри доверенного сайта.
Сервер генерирует непредсказуемый токен и связывает его с сессией пользователя. Токен помещается в форму или становится доступным клиентскому коду доверенного источника, а при изменяющем состояние запросе отправляется в теле запроса или специальном заголовке.
При обработке сервер проверяет сразу два условия: сессия действительна, а полученный токен соответствует ожидаемому для этой сессии. Значение токена нельзя считать пользовательскими данными: его нужно сравнивать безопасным способом, а отсутствие, неверный формат или несовпадение должны приводить к отказу.
Возможны два распространённых варианта. При синхронном токене сервер хранит значение в сессии и сравнивает с присланным токеном. При двойной отправке cookie сервер сопоставляет токен из cookie с токеном из тела или заголовка; этот вариант требует аккуратной защиты cookie и корректной проверки происхождения значения.
SameSite-cookie может уменьшить риск CSRF, ограничивая отправку cookie в межсайтовых сценариях, но политика зависит от режима и типа запроса. Поэтому для критичных операций обычно применяют несколько мер: CSRF-токен, подходящую настройку cookie и, где уместно, проверку заголовков Origin или Referer.
CSRF-токен не является заменой аутентификации и авторизации. Он подтверждает, что запрос, вероятно, сформирован доверенным приложением, но сервер всё равно должен отдельно проверить права пользователя на операцию.
Защита также не спасает от XSS: скрипт, выполняющийся в контексте доверенного сайта, может прочитать токен или отправить запрос через легитимный интерфейс. Кроме того, операции, изменяющие состояние, не следует размещать за безопасными для чтения методами вроде GET.
В личном кабинете изменение номера телефона выполнялось POST-запросом, но сервер проверял только cookie-сессию. Рассматривались три варианта: полагаться только на SameSite-cookie, проверять заголовок Referer или добавить CSRF-токен.
Одна лишь SameSite-политика уменьшала риск, но зависела от браузерных условий и не давала единого серверного контроля. Проверка Referer могла работать не для всех клиентов и зависела от наличия заголовка. Выбрали синхронный CSRF-токен, передаваемый в форме, дополнительно сохранив подходящую настройку SameSite и проверку Origin для поддерживаемых браузерных запросов.
В результате запрос без токена стал отклоняться даже при наличии действительной сессии. При этом права на изменение номера телефона продолжили проверяться отдельно, а XSS-сканирование осталось обязательной частью защиты, поскольку CSRF-механизм не противостоит выполнению кода внутри доверенного источника.
Обычно это ограничивает политика одного источника браузера: страница другого источника может инициировать некоторые запросы, но не получает произвольный доступ к содержимому ответа доверенного сайта. Поэтому злоумышленник может попытаться отправить запрос с cookie, но не знает значение токена, размещённого в форме или полученного через защищённый запрос.
Это ограничение не следует считать абсолютным: ошибочная настройка CORS, XSS, утечка токена или другой обход политики одного источника может его устранить. Следовательно, токен должен оставаться непредсказуемым и не раскрываться через URL, журналы или сторонние источники.
Если запрос действительно не изменяет состояние и не вызывает побочных эффектов, CSRF-токен обычно не нужен. Основной риск CSRF связан с несанкционированным выполнением действия от имени пользователя.
Однако граница должна быть реальной: запрос чтения не должен менять настройки, создавать ресурсы, отправлять сообщения или запускать чувствительную операцию. Если архитектура нарушает это правило, безопаснее считать запрос изменяющим состояние и применять защиту.
Токен и проверка источника подтверждают разные свойства. Токен доказывает наличие значения, которое внешняя страница обычно не может получить, а Origin или Referer дают серверу информацию о том, откуда был инициирован запрос.
Проверка источника может быть дополнительным барьером, но заголовок может отсутствовать или обрабатываться с учётом особенностей конкретного клиента и политики приватности. Поэтому её нельзя безоговорочно считать единственной защитой, а итоговый набор мер выбирают с учётом браузеров, API-клиентов и требований системы.