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

Что такое CSRF и как это работает

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

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

Почему CSRF особенно опасен именно для защищённых зон

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

Чаще всего CSRF-атаки проявляются именно на сайтах с формами, которые изменяют состояние (то есть POST-запросы и схожие методы, меняющие данные на сервере). В идеале такие запросы всегда должны быть защищены от подделки: не просто принимать запросы, а удостоверяться, что запрос действительно был инициирован самим пользователем на сайте, а не кем-то со стороны.

Реальные примеры из моего опыта

В одном из небольших проектов, которые я поддерживал, была форма изменения email пользователя. Вроде бы ничего страшного, но я заметил, что при отправке формы брались только поля email и пароля, а никакие CSRF-токены там не стояли. Решил проверить на тестовом сервере через простой html-файл с формы на другом домене — запрос спокойно проходил и менял email пользователя без его ведома!

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

На другом проекте, где было много AJAX-запросов к REST API, изначально тоже не было защиты от CSRF. Там помогли специальные заголовки (например, X-CSRF-Token) и синхронизация токенов между клиентом и сервером — теперь сервер просто не принимает запросы без валидного токена и правильного origin.

Чек-лист по защите от CSRF

- Использовать CSRF-токены в формах: создавайте уникальный токен при загрузке страницы и проверяйте его при получении POST, PUT, DELETE-запросов.
- Проверять заголовки Origin и Referer на сервере, чтобы убедиться, что запрос пришёл с вашего домена.
- Никогда не использовать GET-запросы для действий, меняющих состояние (например, удаление данных или изменения). GET должен быть «безопасным» и только для чтения.
- В AJAX и API-запросах реализовать отправку и проверку CSRF-токенов через заголовки.
- Использовать современные веб-фреймворки, которые имеют встроенные механизмы защиты от CSRF: Laravel, Django, ASP.NET Core и тому подобное.
- Обеспечить актуальность и своевременное обновление фреймворков и библиотек, чтобы не оставлять известные уязвимости открытыми.
- Анализировать и мониторить логи на предмет подозрительных POST-запросов с других источников и доменов.
- Настраивать CORS корректно, хотя сама настройка CORS — это не защита от CSRF, а скорее дополнительный барьер.

Распространённые ошибки, которые я видел у коллег и в чужих проектах

- Отсутствие CSRF-токенов вообще. Очень часто видел сайты, которые просто не заморачиваются с этими вещами.
- Неправильная или неуникальная генерация токенов – например, токены, которые не меняются между сессиями, или простые токены типа «123456».
- Не проверять заголовки Origin или Referer, а рассчитывать только на токены – а вдруг токен украли каким-то способом? Всегда нужна комплексная проверка.
- Использование GET-запросов для изменения данных – ну это классика, и такой подход практически гарантирует уязвимость.
- Игнорирование защиты в API и AJAX — бывает, что сайты защищают только HTML-формы, а запросы с фронта не проверяют вообще.
- Использование устаревших версий фреймворков и CMS, которые не поддерживают новые методы защиты или в которых есть известные дыры.
- Надежда только на настроенный Secure и HttpOnly флаги куков — это защищает куки от кражи через JavaScript, но не спасает от CSRF, потому что куки всё равно отправляются автоматом.

Часто задаваемые вопросы про CSRF

Нужно ли ставить защиту на все POST-запросы?
Да, лучше защищать все запросы, которые изменяют состояние или данные пользователя, особенно POST, PUT, DELETE. Даже если кажется, что контент не критичный, лучше перестраховаться.

Можно ли доверять только заголовку Referer?
Нет, такой заголовок легко подделать, и иногда в корпоративных сетях или через прокси он может просто отсутствовать вообще. Лучше комбинировать проверку Referer, Origin и CSRF-токены.

Почему не хватает в защите только куки с HttpOnly и Secure?
HttpOnly защищает куки от доступа через JavaScript, Secure ограничивает их передачу только через HTTPS. Но CSRF эксплуатирует то, что браузер сам автоматически посылает эти куки на сервер при запросах — тут уже куки никак не помогают.

А как CORS связан с CSRF?
CORS (Cross-Origin Resource Sharing) регулирует, какие сайты могут делать AJAX-запросы на ваш API и читать ответы. Он не препятствует отправке POST-запросов из форм или других способов. Поэтому CORS – это не полноценная защита от CSRF, CSRF требует серверных проверок.

Как правильно реализовать CSRF-токены на практике?
Объёмный вопрос, но вкратце: сервер при генерации страницы создаёт уникальный, временный токен и кладёт его в поля форм или в cookie. При отправке формы клиент передаёт этот токен обратно серверу, который сравнивает значение с ожидаемым. Если токены не совпадают или отсутствуют – сервер отклоняет запрос.

Что делать, если у вас SPA или мобильное приложение?
Там CSRF тоже можно и нужно предотвращать, например, использовать безопасные заголовки, OAuth-токены и разные другие механизмы аутентификации, чтобы запросы были валидными и исходили именно от клиента, а не от сторонних источников.

Итоги

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

А у вас как с CSRF? Как вы реализуете защиту в своих проектах, какие фреймворки или техники помогли — или наоборот, что подводило? Делитесь, интересно почитать живой опыт!