CSRF — это тема, которая часто у многих вызывает вопросы и недопонимание, несмотря на то, что давно всем известна. Давайте разберёмся с этим понятием максимально просто и подробно, чтобы каждый мог понять, как такие атаки работают и, самое главное, как от них защититься.

Что такое CSRF и почему это опасно
CSRF, или Cross-Site Request Forgery, переводится как «межсайтовая подделка запроса». Суть в том, что злоумышленник заставляет браузер пользователя с уже активной сессией на каком-то сайте выполнить нежелательные действия — например, сменить пароль, перевести деньги или удалить запись. При этом сам пользователь даже не осознаёт, что что-то происходит, потому что это происходит в фоне, без его ведома.

Почему так происходит? Веб-браузеры автоматически отправляют куки сессии при запросах к сайту, если пользователь уже залогинен. Если злоумышленник умудрится отправить запрос с помощью браузера жертвы к нужному сайту, гораздо проще выполнить вредоносные действия. Сама сессия пользователя даёт злоумышленнику возможность «слизать» права и провести операции от лица пострадавшего.

Где CSRF особенно актуален
Те сайты, где важна авторизация и есть действия, меняющие состояние — вот простые кандидаты для CSRF. Это социальные сети, банковские сервисы, форумы, личные кабинеты и даже админ-панели сайтов. Практически любой крупный ресурс с пользователями и возможностью «редактирования» рискует попасть под такую атаку, если не реализует защиту.

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

Конкретные жизненные примеры CSRF
1. Представьте, вы вошли в социальную сеть и параллельно, в другом табе браузера, открыта странная страница. Там под видом обычной картинки загружен скрытый запрос POST, который меняет ваш email в соцсети. Вы не заметили, смена прошла нелегитимно, но именно вы невольно отправили эту команду сайту.
2. Допустим, есть административная панель, из которой можно удалить пользователей. Если запрос на удаление не защищён CSRF-токеном, злоумышленник просто создаёт на своём сайте форму с таким запросом и заманивает админа кликнуть по ссылке. В итоге пользователь удалён без ведома админа.
3. Ещё пример — при настройке API без правильной CSRF-защиты: отправка POST-запросов с помощью JavaScript с других сайтов в обход авторизации. Это особенно опасно, если API отвечает за критичные операции: переводы, заказ товаров, изменения настроек.

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

Как правильно защищаться — чек-лист для веб-разработчиков и админов
- Всегда генерируйте уникальные CSRF-токены для каждой сессии и каждого пользователя.
- Интегрируйте токены во все формы, которые вызывают операции изменения данных, включая AJAX-запросы.
- Никогда не используйте GET для действий, которые что-то меняют.
- Проверяйте заголовки Referer и Origin для подтверждения легитимности запроса.
- Используйте флаг SameSite для cookies — это ограничивает отправку куки только с вашего домена и блокирует отправку из внешних сайтов.
- При реализации API применяйте другие схемы защиты, например, авторизацию через токены (JWT и пр.) и CORS с правильной конфигурацией.
- Проверяйте работу защиты при помощи специализированных инструментов и ручного тестирования.

Работа с дополнительными инструментами
Среди полезных решений для борьбы с CSRF можно выделить OWASP CSRFGuard — она отлично встраивается в Java-приложения и автоматически ставит и проверяет токены. Для других языков и фреймворков тоже есть подобные библиотеки, например, Django, Laravel, Spring Security, Express и так далее. Многие из них имеют встроенную защиту, но не всегда она включена и настроена по умолчанию, тут надо быть внимательными.

Также стоит обратить внимание на настройки cookies: установка параметра SameSite=strict или lax помогает ограничить отправку cookies только в пределах настоящих сессий. Это очень простой и мощный способ затруднить внешним ресурсам использование куков пользователя.

FAQ по CSRF
Вопрос: Можно ли обойти CSRF-защиту с помощью JavaScript?
Ответ: Современные браузеры не позволяют отправлять кросс-доменные запросы с куками без спецнастроек (CORS). А CSRF-токены и заголовки Referer/Origin не предоставляют злоумышленнику нужной информации, если защита на сервере реализована правильно. Так что обойти сложную защиту без уязвимостей в коде почти невозможно.

Вопрос: А что делать, если у меня старый движок, где CSRF-токен не предусмотрен?
Ответ: Обновлять или дописывать защиту. Иногда можно добавить перехватчики запросов или внедрить прокси, который проверяет заголовки и ограничивает опасные операции через POST с валидным токеном.

Вопрос: Почему нельзя использовать простой пароль в параметрах GET для защиты от CSRF?
Ответ: Потому что GET-запросы могут быть легко подделаны, раскрыты в логах и браузерах, а параметры в URL видны публично. CSRF требует секретов, которые не передаются в URL и непредсказуемы.

Вопрос: Нужна ли CSRF-защита для REST API?
Ответ: Часто нет, если API требует авторизации через токены в заголовках (Bearer, API keys), а не за счёт cookie сессии. Но если в API используются cookie, CSRF-атаки возможны, и защиту делать нужно.

В заключение
CSRF — далеко не «страшилка» и далеко не сложно понять, если копнуть. Главное — помнить, что атака работает через доверие браузера к сайтам, на которых вы залогинены. Разработчикам стоит тщательно проверять, как реализованы формы и API, админам — настраивать правильное поведение куки и оберегать критичные операции с помощью токенов.

Если у вас есть вопросы по реализации защиты в конкретных фреймворках или языках, или хотите поделиться своим опытом — пишите! Это реально важная тема для любого, у кого есть сайт или сервис, так что делимся знаниями и помогаем друг другу понять нюансы.