CSRF — тема, с которой сталкивалась почти каждая веб-разработка или админка, особенно если сайта касается пользовательская авторизация и изменения важных данных. Сейчас разложу по полочкам, что это за атака, как она работает, и как реально от нее защититься, без занудных объяснений и технических формул.

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

Чем это плохо? По сути, злоумышленник использует твою залогиненую сессию, чтобы делать что угодно. Ты вроде как ничего не сделал, но на сайте произошла атака именно от твоего имени. Самое страшное, что ты даже не заметишь — ведь действия идут «легитимным» способом.

Примеры атак CSRF на практике

1. Смена email или пароля
Пусть у вас на сайте есть форма, где можно поменять email по POST-запросу. Если нет защиты от CSRF, злоумышленник может создать на своём сайте такой кусок кода:

<form action="https://ваш-сайт.ru/change-email" method="POST" style="display:none;">
<input type="email" name="new_email" value="hacker@evil.com">
</form>
<script>document.forms[0].submit()</script>

Когда залогиненный пользователь просто откроет эту страницу, его email на вашем сайте изменится автоматически.

2. Перевод денег или оформление заявки
Аналогично можно запрограммировать скрытый отправленный на сайт запрос для перевода денег или размещения товара, который при отсутствии души на стороне сервера просто пройдет.

3. Социальные сети
Даже лайк, репост или подписка могут быть осуществлены без ведома пользователя, если там есть соответствующий GET или POST-запрос и нет защиты.

Типичные ошибки при защите от CSRF

- Использование GET-запросов для операций, которые меняют что-то на сервере. Это моветон и одна из главных причин проблем. Всегда используйте POST для действий, меняющих данные.
- Отсутствие CSRF-токенов. Самый массовый прокол. Многие думают, что просто проверить сессию — достаточно, но нет. Токены нужны, чтобы подтвердить, что запрос исходит от твоей формы.
- Токены передаются в URL или куках — так их легко украсть через логи или соседние скрипты. Лучше передавать в теле POST-запроса.
- Не валидировать токены на сервере, либо делать это неправильно (например, не сравнивать полностью или не проверять срок действия).
- Не обновлять токен после его использования — тогда злоумышленник может воспользоваться одним и тем же токеном много раз.
- Игнорирование проверки заголовков Origin или Referer — иногда можно отфильтровать запросы с других сайтов, особенно если API открытый.
- Плохая настройка cookie SameSite — если куки авторизации настроены неправильно, то браузер будет отправлять их и с чужих сайтов, что облегчает атаку.

Как защититься от CSRF

1. CSRF-токены
Самое главное — добавить токены в формы и проверять их на сервере. При каждом заходе пользователя генерируешь уникальный токен и вписываешь в форму скрытым полем. При отправке проверяешь, совпадает ли он с тем, что у тебя хранится. Библиотеки типа Django, Laravel, Spring Security делают это за тебя, и стоит этим пользоваться!

2. Заголовки Origin и Referer
Можно проверять, с какого сайта пришел запрос, и отклонять запросы, если они откуда-то еще. Но это не панацея — иногда заголовки могут отсутствовать (например, в некоторых браузерах или при прокси).

3. SameSite для куки
Убеждаемся, что сессионные куки имеют атрибут SameSite, желательно strict или lax — они запретят отправлять эти куки на сторонние сайты при кросс-доменных запросах.

4. Использование POST, а не GET
Ни в коем случае не меняйте данные через GET-запросы. GET должен только читать данные.

5. Обновлять токен после использования
Чтобы злоумышленник не мог использовать одинаковый токен многократно.

6. Минимизировать использование сторонних скриптов и iframe из ненадежных источников, т.к. они могут быть использованы для запуска CSRF-атак.

Чек-лист для борьбы с CSRF

- Везде, где есть формы или любые запросы, меняющие состояние, использовать CSRF-токен и правильно его проверять.
- Запретить любые изменения через GET-запросы.
- Настроить сессионные куки с флагом SameSite (strict/lax).
- Проверять Origin/Referer заголовки, если есть такая возможность.
- Обновлять CSRF-токен после каждой операции.
- Не передавать токены в URL или cookie. Использовать скрытые поля формы.
- Использовать проверенные фреймворки и библиотеки, которые уже включают защиту от CSRF.
- Следить, чтобы API имел свои механизмы авторизации и защиты, особенно если открытый для внешних вызовов.

FAQ по CSRF

В: А разве современные браузеры не защищают от этого?
О: Частично — атрибут SameSite для куки появился не так давно и помогает, но далеко не все сайты и браузеры его используют правильно. И это не панацея.

В: Чем CSRF отличается от XSS?
О: CSRF — атака с чужого сайта, заставляющая твой браузер сделать запрос от твоего имени. XSS — внедрение скрипта прямо на сайт, позволяющего злоумышленнику выполнять произвольный код.

В: Что делать, если у меня API и клиенты не всегда с браузера?
О: Тогда лучше использовать токены авторизации типа JWT и методы аутентификации на стороне API — CSRF там менее актуально, если запросы идут с корретными заголовками и проверками.

В: А что делать с AJAX?
О: В AJAX тоже нужно передавать CSRF-токены в заголовках или теле запросов. Многие фреймворки позволяют автоматически вставлять CSRF-токен в AJAX запросы.

В: Как проверить, есть ли у меня уязвимость?
О: Можно написать простую страницу с формой на чужом сайте, которая будет отправлять запросы к вам и смотреть, сработают ли действия. Или использовать специализированные инструменты тестирования безопасности.

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

Все, теперь ваша очередь — кто чем защищается и сколько раз уже спасался от CSRF? Делитесь лайфхаками и историями!