CSRF расшифровывается как Cross-Site Request Forgery, то есть межсайтовая подделка запроса. Это тип веб-атаки, при котором злоумышленник не взламывает пароль пользователя напрямую, а заставляет его браузер отправить запрос в сервис, где пользователь уже авторизован. Для бизнеса опасность CSRF в том, что действие выглядит как обычное действие реального клиента, сотрудника или администратора.
Представим интернет-банк, CRM, личный кабинет поставщика или панель управления интернет-магазином. Пользователь вошел в аккаунт, браузер хранит сессию в cookie. Затем пользователь открывает вредоносную страницу, письмо с HTML-содержимым или переходит по ссылке. Эта страница незаметно отправляет запрос в доверенный сервис. Если сервис принимает запрос только потому, что к нему приложились cookie авторизованной сессии, действие может выполниться без осознанного согласия пользователя.
CSRF часто путают с XSS. При XSS злоумышленник внедряет скрипт в страницу атакуемого сайта. При CSRF злоумышленник использует доверие сайта к браузеру пользователя. То есть проблема не в том, что пользователь ввел пароль на поддельной странице, а в том, что приложение не проверило, действительно ли запрос был создан его собственным интерфейсом.
Простое объяснение
Веб-приложение обычно узнает пользователя по сессионной cookie. Когда пользователь авторизован, браузер автоматически прикладывает cookie к запросам на нужный домен. Это удобно: клиенту не нужно вводить пароль при каждом клике. Но эта же автоматизация создает риск. Если другой сайт сможет инициировать запрос к приложению, браузер может приложить cookie сам, а сервер увидит запрос как авторизованный.
CSRF использует именно это поведение. Атакующий не обязан знать пароль, токен сессии или содержимое cookie. Ему достаточно знать, какой URL или форма выполняет важное действие, например смену пароля, добавление пользователя, подтверждение платежа или изменение прав доступа.
Ключевая идея CSRF: браузер пользователя действует как доверенный посредник, а сервер не отличает намеренный запрос от подделанного.
Как работает CSRF по шагам
- Пользователь входит в веб-приложение, например в корпоративную CRM или панель администратора.
- Приложение создает сессию, а браузер сохраняет cookie.
- Пользователь не выходит из аккаунта и открывает другую страницу, созданную злоумышленником.
- Вредоносная страница формирует запрос к доверенному приложению.
- Браузер автоматически добавляет cookie сессии к запросу.
- Сервер принимает запрос как действие авторизованного пользователя.
Если приложение не использует защитные механизмы, сервер может выполнить действие. Для пользователя это может выглядеть как непонятная смена настроек, неожиданная операция или появление нового администратора. Для компании это уже инцидент безопасности.
Пример атаки
Допустим, в административной панели есть действие смены email:
POST /account/email email=attacker@example.comЕсли сервер проверяет только наличие активной сессии, злоумышленник может разместить на своей странице форму, которая отправит такой запрос. Пользователь откроет страницу, браузер приложит cookie, а приложение примет действие за легитимное. В реальной системе такие действия обычно должны дополнительно проверяться CSRF-токеном, подтверждением пользователя или повторной аутентификацией.
Упрощенный пример небезопасной логики:
if user_is_logged_in: change_email(request.email)Более безопасная логика выглядит иначе:
if user_is_logged_in and csrf_token_is_valid and action_is_expected: change_email(request.email)Смысл защиты не в том, чтобы скрыть URL. URL и параметры часто можно узнать из интерфейса, документации, истории браузера или сетевых запросов. Смысл в том, чтобы сервер требовал доказательство: запрос был создан именно доверенной страницей приложения.
Где CSRF особенно опасен
CSRF наиболее критичен там, где веб-запрос меняет состояние системы. Это не только финансовые операции. Для бизнеса риск может быть связан с доступами, конфиденциальными данными, настройками интеграций и цепочками поставок.
| Сценарий | Что может произойти | Бизнес-риск |
|---|---|---|
| Личный кабинет клиента | Смена email, телефона или адреса доставки | Захват аккаунта, мошеннические заказы, потеря доверия |
| Интернет-банк или платежный сервис | Инициирование перевода или изменение шаблона платежа | Финансовые потери и претензии клиентов |
| CRM | Изменение сделки, контакта или статуса клиента | Ошибки продаж, утечка коммерческих данных |
| Админ-панель сайта | Создание нового пользователя с правами администратора | Компрометация всей платформы |
| Сервис рассылок | Изменение шаблона письма или списка получателей | Фишинг от имени компании, репутационный ущерб |
| DevOps-панель | Изменение webhook, ключей интеграций или настроек окружения | Нарушение поставки ПО и доступ к инфраструктуре |
Почему CSRF остается актуальным
Современные браузеры и фреймворки стали лучше защищать приложения. Например, cookie могут иметь атрибут SameSite, а многие веб-фреймворки включают CSRF-защиту по умолчанию. Но риск не исчез. Он часто появляется из-за ручных API-эндпоинтов, старых форм, отключенной защиты, нестандартной авторизации, слабой конфигурации cookie или ошибочного представления, что JSON API неуязвимы.
Особенно часто проблемы возникают в системах, которые развивались много лет. В одном модуле используется современный фреймворк и токены, а в другом осталась старая форма без защиты. Пользовательский интерфейс может выглядеть единым, но серверная логика защищена неравномерно.
Какие запросы нужно защищать
Главное правило: защищать нужно все запросы, которые меняют состояние. Это касается создания, редактирования, удаления, подтверждения, отмены и запуска процессов. Запросы только для чтения менее опасны, но и они могут раскрывать данные, если дополнительно есть ошибки в CORS, кэшировании или политике доступа.
- Смена пароля, email, телефона и других учетных данных.
- Добавление или удаление пользователей.
- Изменение ролей и прав доступа.
- Создание заказов, заявок, платежей и возвратов.
- Изменение настроек безопасности.
- Подключение внешних интеграций и webhook.
- Удаление файлов, записей, проектов или рабочих пространств.
- Подтверждение юридически значимых действий, если они выполняются через веб-интерфейс.
Нежелательно выполнять изменяющие операции через GET-запросы. GET должен использоваться для получения данных, а не для действий вроде удаления записи или смены настройки. Если ссылка вида /delete?id=15 удаляет объект, это удобная цель для CSRF.
Основные способы защиты
CSRF-токен
Самый распространенный способ защиты — CSRF-токен. Сервер генерирует уникальное значение, вставляет его в форму или передает клиентскому приложению безопасным способом. При отправке формы или запроса клиент возвращает токен. Сервер проверяет, совпадает ли он с ожидаемым значением.
Злоумышленник может заставить браузер отправить запрос, но не должен иметь доступ к корректному токену. Поэтому запрос без токена или с неправильным токеном отклоняется.
SameSite для cookie
Атрибут SameSite ограничивает отправку cookie в межсайтовых сценариях. Значение Lax часто снижает риск для обычных переходов и форм, Strict дает более жесткое поведение, а None требует HTTPS и используется для сценариев, где cookie должны работать между сайтами. Но SameSite не стоит считать единственной защитой. Его нужно применять вместе с токенами и правильной архитектурой.
Проверка Origin и Referer
Сервер может проверять заголовки Origin и Referer, чтобы понять, откуда пришел запрос. Если важное действие пришло не с ожидаемого домена, запрос можно отклонить. Этот подход полезен как дополнительный слой, но не должен быть единственной защитой во всех случаях: заголовки могут отсутствовать по причинам приватности, сетевой инфраструктуры или особенностей клиента.
Повторная аутентификация
Для особо важных действий полезно требовать повторного подтверждения: ввод пароля, одноразовый код, подтверждение через приложение или аппаратный ключ. Это не замена CSRF-токенам, а дополнительный барьер для операций с высоким риском.
Правильные HTTP-методы
Операции чтения должны выполняться через GET, а изменения — через POST, PUT, PATCH или DELETE. Но сам по себе POST не защищает от CSRF. Он только делает поведение приложения более корректным и упрощает применение защитных механизмов.
Типичные ошибки при защите
| Ошибка | Почему это опасно | Как лучше |
|---|---|---|
| Считать, что POST сам по себе безопасен | Вредоносная страница тоже может отправить форму POST | Проверять CSRF-токен и источник запроса |
| Отключить CSRF-защиту для удобства API | Часть браузерных клиентов остается уязвимой | Разделять браузерные сессии и API-авторизацию |
| Использовать один токен навсегда | Утечка токена надолго ломает защиту | Привязывать токен к сессии и обновлять его |
| Защищать только формы, но не AJAX-запросы | Важные действия часто выполняются через JavaScript | Единообразно проверять все изменяющие запросы |
| Полагаться только на Referer | Заголовок может отсутствовать или быть нестабильным | Использовать Referer как дополнительную проверку |
| Выполнять действия через GET | Действие можно вызвать ссылкой, картинкой или редиректом | Не менять состояние через GET |
CSRF в бизнес-контексте
Для бизнеса CSRF важен не как абстрактная техническая уязвимость, а как источник несанкционированных действий от имени доверенных пользователей. В журналах событий такие действия могут выглядеть легитимно: запрос пришел от реального аккаунта, с реальной сессией, иногда даже с привычного IP-адреса. Это усложняет расследование и коммуникацию с клиентом.
В B2B-системах последствия особенно неприятны. Один администратор может управлять пользователями всей компании-клиента. Если его браузер отправит поддельный запрос, злоумышленник может получить доступ к данным организации, изменить настройки SSO, добавить интеграцию или создать токен доступа. Даже если ущерб быстро замечен, доверие к платформе снижается.
В e-commerce CSRF может использоваться для смены адреса доставки, добавления товара, применения купона, изменения платежных настроек или привязки аккаунта к другому email. В финансовых сервисах риск выше, поэтому важные операции обычно защищают несколькими слоями: токенами, подтверждениями, лимитами и антифрод-логикой.
Как проверить приложение на CSRF
Проверка начинается с инвентаризации действий, которые меняют состояние. Нужно пройти по основным ролям пользователей и перечислить операции: профиль, платежи, роли, настройки, интеграции, файлы, приглашения, уведомления, API-ключи. Затем для каждого действия проверяется, требует ли сервер CSRF-токен или другой надежный механизм подтверждения.
- Откройте приложение в браузере и выполните важное действие.
- Посмотрите запрос в инструментах разработчика или прокси для тестирования.
- Удалите CSRF-токен из запроса и повторите его.
- Замените токен на случайное значение и повторите запрос.
- Проверьте, выполняется ли действие без корректного Origin или Referer.
- Убедитесь, что GET-запросы не меняют состояние.
- Проверьте разные роли: обычный пользователь, менеджер, администратор.
Если действие выполняется без токена или с неверным токеном, это серьезный сигнал. Если защита есть только в интерфейсе, но сервер принимает прямой запрос без проверки, защита считается недостаточной.
CSRF и API
Многие команды считают, что CSRF относится только к классическим HTML-формам. На практике это зависит от способа авторизации. Если API вызывается из браузера и использует cookie-сессию, риск CSRF сохраняется. Если API использует bearer-токен в заголовке Authorization и этот токен не прикладывается браузером автоматически, риск обычно ниже, но появляются другие задачи: защита токена от XSS, безопасное хранение и контроль CORS.
Для одностраничных приложений важно понимать, где хранится авторизация. Cookie удобны и могут быть защищены флагами HttpOnly, Secure и SameSite, но требуют CSRF-защиты. Токены в JavaScript-хранилищах могут снижать CSRF-риск, но повышать ущерб от XSS. Поэтому выбор должен учитывать модель угроз, требования продукта и зрелость команды.
Минимальный чек-лист защиты
- Все изменяющие запросы требуют валидный CSRF-токен.
- Токен привязан к сессии и проверяется на сервере.
- Cookie имеют Secure, HttpOnly и подходящее значение SameSite.
- GET-запросы не выполняют изменения.
- Для критичных операций есть повторное подтверждение.
- Проверяются Origin и Referer там, где это уместно.
- CSRF-защита не отключена глобально ради одного проблемного маршрута.
- Тесты покрывают формы, AJAX-запросы и административные операции.
- Ошибки проверки токена логируются, но не раскрывают лишние детали пользователю.
Признаки возможной уязвимости
Уязвимость может быть незаметна при обычном использовании. Пользователь видит кнопку, форма работает, интерфейс выглядит безопасно. Но если сервер принимает запрос без доказательства намерения, CSRF остается возможным. На ревью стоит насторожиться, если важные действия выполняются по простым ссылкам, если токена нет в запросах, если все держится только на cookie или если защита отключена в настройках фреймворка.
Еще один признак — разная защита в разных частях продукта. Например, новый личный кабинет проверяет токены, а старая административная зона, доступная по отдельному пути, работает без них. Такие места часто появляются после миграций, срочных релизов и интеграции старых модулей.
Краткий итог
CSRF — это атака, при которой злоумышленник заставляет браузер авторизованного пользователя выполнить нежелательный запрос в доверенном приложении. Главная причина риска — автоматическая отправка cookie и недостаточная проверка намерения пользователя на стороне сервера.
Базовая защита включает CSRF-токены, корректные HTTP-методы, настройки cookie, проверку источника запроса и повторное подтверждение для критичных операций. Для бизнеса это не только вопрос технической чистоты, но и способ защитить деньги, данные, репутацию и доверие клиентов.
Связанные термины
- XSS — внедрение вредоносного скрипта в страницу, часто опасно в связке с другими веб-уязвимостями.
- Cookie — данные, которые браузер автоматически отправляет на домен сайта.
- SameSite — атрибут cookie, ограничивающий ее отправку в межсайтовых сценариях.
- Session — серверная или клиентская сущность, связывающая запросы с авторизованным пользователем.
- CORS — механизм браузера для контроля междоменных запросов.
- Origin — заголовок, который помогает серверу понять источник запроса.
- Аутентификация — проверка личности пользователя.
- Авторизация — проверка прав пользователя на конкретное действие.
