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

Подделка межсайтовых запросов (CSRF) — один из самых недооценённых видов кибератак. Жертва даже не замечает, что её браузер выполняет вредоносные действия на сайте, где она авторизована. Злоумышленник заставляет систему перевести деньги, сменить пароль или удалить аккаунт — и всё это без ведома пользователя. В 2025 году CSRF по-прежнему фигурирует в списке OWASP Top 10, хотя и переехал в категорию «Security Misconfiguration». Это означает, что большинство уязвимостей возникает не из-за отсутствия защиты, а из-за её неправильной настройки. Разберёмся, как работает CSRF, почему он остаётся опасным и какие методы защиты действительно работают.

Как работает CSRF-атака: принцип и примеры

CSRF-атака возможна при трёх условиях: пользователь авторизован на целевом сайте, сайт доверяет автоматическим механизмам аутентификации (например, куки), и запрос можно сформировать без участия человека. Злоумышленник создаёт вредоносную страницу или email, содержащий скрытую форму или ссылку. Когда жертва открывает этот ресурс, браузер автоматически отправляет запрос на уязвимый сайт, включая куки. Сервер считает запрос легитимным, так как он приходит от авторизованного пользователя.

Классический пример — перевод денег в банковском приложении. Если банк не защищён от CSRF, злоумышленник может встроить в свой сайт картинку с URL вида https://bank.com/transfer?amount=1000&to=attacker. Когда жертва заходит на сайт злоумышленника, браузер запрашивает эту картинку, а фактически отправляет запрос на перевод. Банк видит авторизованную сессию и выполняет операцию. Похожие сценарии возможны в социальных сетях, интернет-магазинах и любых сервисах, где есть действия с изменением данных.

Современные приложения на Next.js часто используют серверные действия (Server Actions) для обработки форм. Если они не защищены, CSRF-атаки могут привести к изменению данных, публикации контента от имени пользователя или даже к компрометации аккаунта. Многие разработчики ошибочно полагают, что использование JSON или CORS-настроек автоматически защищает от CSRF, но это не так. CORS контролирует чтение ответов, а не отправку запросов, поэтому не является преградой для CSRF.

Почему CSRF всё ещё актуален в 2025 году

Несмотря на то, что CSRF известен с начала 2000-х, он не исчез. Одна из причин — появление новых архитектур, таких как одностраничные приложения (SPA) и серверные компоненты. Многие фреймворки, включая Next.js, предоставляют встроенные механизмы защиты, но они работают только при правильной настройке. Например, Next.js автоматически генерирует CSRF-токены для Server Actions, но если разработчик использует кастомные API-маршруты без токенов, уязвимость остаётся.

Кроме того, растёт число атак, использующих CSRF в связке с другими уязвимостями. Например, CSRF может быть использован для обхода CORS-ограничений или для выполнения привилегированных действий через уязвимые прокси. В отчёте OWASP за 2021 год CSRF переехал в категорию «Security Misconfiguration», что означает: чаще всего проблема не в отсутствии защиты, а в её неправильной реализации. Разработчики часто отключают защиту для удобства тестирования или забывают включить её на продакшене.

Как защититься от CSRF: проверенные методы

Самый надёжный способ — использование синхронизированных токенов (CSRF-токенов). Суть в том, что сервер генерирует уникальный токен, который включается в каждый чувствительный запрос (например, в скрытое поле формы или заголовок). Сервер проверяет его наличие и соответствие сессии. Поскольку злоумышленник не может узнать токен, он не сможет сформировать валидный запрос. Этот метод считается золотым стандартом и рекомендуется OWASP.

Второй метод — проверка заголовков Origin и Referer. Сервер должен убедиться, что запрос пришёл с доверенного домена. Однако у этого метода есть ограничения: заголовок Referer может отсутствовать из-за политик конфиденциальности, а Origin подделывается в некоторых старых браузерах. Поэтому проверка Origin работает только как дополнительный уровень защиты, а не основной.

Третий подход — использование SameSite-атрибута для куки. Установка SameSite=Lax или SameSite=Strict ограничивает отправку куки при кросс-сайтовых запросах. Это не панацея, но значительно снижает риск. Vercel рекомендует комбинировать все три метода: токены, проверку Origin и SameSite-куки. Такой подход создаёт многослойную защиту, которая эффективна даже против сложных атак.

Как CSRF-защита реализована в Next.js?

В Next.js App Router встроена защита от CSRF для Server Actions: при вызове действия сервер автоматически генерирует и проверяет токен. Однако это работает только для форм, отправляемых через Server Actions. Если вы используете API-маршруты (Route Handlers), вам нужно реализовать защиту самостоятельно. Vercel советует использовать библиотеки типа csrf-csrf или встроенные middleware для проверки токенов.

Важно также помнить, что если ваше приложение использует сторонние API или вебхуки, они тоже могут быть уязвимы. Например, для вебхуков обычно используют секретные ключи или подписи, но если запрос содержит куки, CSRF-атака может быть направлена и на них. Поэтому необходимо защищать не только пользовательские формы, но и все эндпоинты, которые изменяют данные.

Кого затронет CSRF-уязвимость и как её обнаружить

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

Обнаружить CSRF можно с помощью автоматических сканеров уязвимостей, таких как OWASP ZAP или Burp Suite. Они отправляют тестовые запросы без токенов и проверяют, принимает ли сервер их. Также полезно проводить ручной аудит кода: искать формы, отправляемые методом POST без CSRF-токена, и проверять настройки куки.

В России и СНГ, где популярны самописные CMS и фреймворки, проблема CSRF часто игнорируется. Многие разработчики полагаются на «защиту» через CORS, но это не работает. Поэтому важно обучать команды и внедрять стандартные практики безопасности.

Что дальше: будущее защиты от CSRF

Развитие веб-платформы постепенно делает CSRF менее актуальным. Браузеры ужесточают политики SameSite, а новые стандарты, такие как Fetch Metadata, позволяют серверам отклонять кросс-сайтовые запросы. Например, заголовок Sec-Fetch-Site сообщает серверу, является ли запрос кросс-сайтовым, и его можно использовать для блокировки.

Однако полностью полагаться на браузеры нельзя. Атаки будут эволюционировать, и разработчикам нужно оставаться бдительными. Vercel рекомендует регулярно обновлять зависимости, использовать встроенные механизмы фреймворков и проводить пентесты.

Итог

CSRF-атаки — реальная угроза, которую нельзя игнорировать. Даже если вы используете современный фреймворк, неправильная настройка может сделать ваше приложение уязвимым. Используйте комбинацию токенов, проверки Origin и SameSite-куки, и тогда вы сможете защитить своих пользователей. Следите за обновлениями безопасности и не забывайте о регулярных аудитах — это залог доверия и стабильности вашего сервиса.