CSRF — это когда простое открытие другого сайта, пока вы в системе, без вашего ведома запускает перевод или изменение настроек. Разберём, как он работает и как надёжно его предотвратить (без шагов атаки).
Почему это работает (механизм)
Браузер автоматически прикрепляет куки сайта к запросам к этому сайту. Поэтому если пользователь вошёл в свой банк, запрос к банку, инициированный с вредоносной страницы, всё равно несёт «куки пользователя». Для сервера он неотличим от легитимного действия.
Если XSS «выполняет код в браузере жертвы», то CSRF «заимствует активный сеанс жертвы» (→ Что такое XSS).
Защита
Требуйте CSRF-токен
На действиях, меняющих состояние (отправка форм, API), требуйте непредсказуемый одноразовый токен, выданный сервером; отклоняйте запросы без него. Большинство фреймворков это поставляют.
Установите куки SameSite
Помечайте сеансовые куки SameSite=Lax (или Strict), чтобы куки не прикреплялись к запросам, исходящим с других сайтов. Lax — современное значение по умолчанию и сам по себе сильно помогает.
Не используйте GET для изменений состояния
GET (просмотр) не должен иметь побочных эффектов. Делайте изменения через POST/PUT/DELETE и пропускайте их через проверку токена.
Проверяйте Origin / Referer
Для чувствительных действий убедитесь, что Origin запроса — ваш собственный сайт, и отклоняйте внешние источники.
Мнение этого сайта: в основном «решено», но не расслабляйтесь
CSRF-токены фреймворков плюс значение SameSite=Lax по умолчанию в браузерах резко сократили классический CSRF. И всё же он встречается в самописных API, легаси-настройках и админ-панелях, где про токен забыли. Даже если вы «доверяете это фреймворку», один раз сами проверьте, что пути, меняющие состояние, действительно выполняют проверку токена.
Частые пробелы
Даже зная механизм, реализации обычно проскальзывают в двух местах.
- GET с побочными эффектами: если просматривающий GET меняет состояние, для CSRF достаточно тега изображения или обычной ссылки. Делайте изменения состояния через POST/PUT/DELETE и пропускайте их через проверку токена.
- Забытая проверка токена на части путей: API и админ-функции, добавленные позже, часто пропускают токен. Не считайте, что «во фреймворке это есть» — один раз проинвентаризируйте каждый путь, меняющий состояние.
CSRF, XSS и SSRF
Эти три похожих названия различаются тем, кто отправляет запрос и на что опирается атака.
| Атака | Кто отправляет запрос | Чем злоупотребляют | Основная защита |
|---|---|---|---|
| CSRF | Браузер пользователя без его ведома | Автоматическое прикрепление кук браузером | CSRF-токены, куки SameSite |
| XSS | Скрипт атакующего, выполняющийся в браузере пользователя | Отсутствие экранирования при выводе страницы | Экранирование на выводе, CSP |
| SSRF | Ваш сервер | Функция, загружающая переданный ей URL | Список разрешённых адресатов, блокировка внутренних адресов |
CSRF и XSS оба работают через браузер пользователя. Но если на странице есть XSS, скрипт внутри неё может прочитать CSRF-токен, и защита от CSRF обходится. Защита от CSRF исходит из того, что XSS уже устранён.
Реальный пример: поддельная публикация, принятая за действие пользователя
В 2012 году через форму для мнений на сайте мэрии Иокогамы была опубликована угроза напасть на начальные школы. Владелец компьютера, с которого она будто бы пришла, был арестован, а позже выяснилось, что арест был ошибкой. В декабре того же года полиция Токио, по сообщениям японской прессы, объяснила, что публикация была отправлена с помощью CSRF: браузер посетителя заставили отправить её после того, как он открыл ссылку, размещённую на форуме.
Из этого следуют два урока.
- Запрос CSRF выглядит точно так же, как собственный запрос пользователя: сервер видит только IP-адрес и куки пользователя. По одним логам нельзя понять, отправил ли пользователь запрос сам или его заставили.
- Формы без входа тоже в зоне риска: та форма для мнений не требовала входа. Ставьте токен на любую отправку, которую вы не хотели бы, чтобы запускали другие (публикации, заявки, сообщения), — независимо от того, нужен ли вход.
CSRF по-прежнему распространённая слабость. В «CWE Top 25» MITRE (25 самых опасных слабостей ПО), опубликованном в декабре 2025 года, CSRF (CWE-352) занял третье место.
Как проверить свой сайт
Явно задайте SameSite для сеансовых кук
Проверьте атрибут SameSite сеансовой куки в инструментах разработчика браузера (Application → Cookies) или с помощью аудита сайта. Chrome и Edge считают куки без атрибута Lax, но Safari и Firefox по умолчанию так не делают. Не полагайтесь на поведение браузера по умолчанию; задайте SameSite=Lax или Strict сами.
Пересмотрите исключения из защиты CSRF
Проверьте, не отключена ли защита CSRF фреймворка для части маршрутов (csrf_exempt в Django, список исключений в Laravel, skip_forgery_protection в Rails и т. п.). Где для отключения есть причина — например, приём вебхуков, — защитите маршрут проверкой подписи.
Найдите GET-маршруты, меняющие состояние
Пройдитесь по списку маршрутов в поисках GET-маршрутов, которые удаляют, обновляют или выполняют выход. Переведите их на POST или аналог и пропускайте через проверку токена.
Добавьте ещё одну проверку для чувствительных действий
Для смены пароля или адреса почты, перевода денег или выдачи прав запрашивайте, помимо токена, текущий пароль или многофакторную аутентификацию. Даже если запрос подделан, его остановит подтверждение пользователем.
Источники (первичные)
- OWASP, «Cross-Site Request Forgery Prevention Cheat Sheet» — cheatsheetseries.owasp.org (токены, Sec-Fetch-Site, ограничения SameSite, обход защиты CSRF через XSS, никаких изменений состояния через GET)
- MITRE, «2025 CWE Top 25 Most Dangerous Software Weaknesses» (декабрь 2025 г.) — cwe.mitre.org (CWE-352 на третьем месте)
- web.dev, «SameSite cookies explained» — web.dev (какие браузеры считают куки без атрибута Lax)
- INTERNET Watch, материал о деле с вредоносным ПО для удалённого управления (14 декабря 2012 г., на японском) — internet.watch.impress.co.jp (объяснение полиции, что для публикации в Иокогаме использовался CSRF)
- @IT, статья об ошибочных арестах из-за вредоносного ПО для выдачи себя за другого и CSRF (ноябрь 2012 г., на японском) — atmarkit.itmedia.co.jp
- IPA, «How to Secure Your Web Site» — ipa.go.jp (на японском)
Читать дальше
- Глоссарий: Что такое XSS · Что такое SSRF
- Основы: Основы безопасности