Источник: https://github.com/AnaktaCTF/CTF/blob/main — WEB/CSRF.md

1. Введение в CSRF

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

2. Как работает CSRF?

CSRF-атака обычно проходит по следующему сценарию:

  1. Пользователь авторизуется на сайте и его сессия сохраняется (например, с помощью cookies).
  2. Злоумышленник подготавливает вредоносную ссылку или форму, отправляющую запрос к целевому сайту.
  3. Жертва переходит по ссылке или открывает вредоносную страницу, которая автоматически отправляет запрос от ее имени.
  4. Сервер принимает запрос, так как он исходит от авторизованного пользователя, и выполняет нежелательное действие (например, перевод денег, изменение пароля, удаление данных и т. д.).

3. Как находить CSRF-уязвимости?

3.1. Поиск небезопасных методов

CSRF-уязвимости чаще всего возникают в HTTP-запросах методов GET и POST, если на сервере нет механизма защиты (например, CSRF-токенов).

Пример потенциально уязвимого запроса:

GET /change_email?new_email=attacker@example.com HTTP/1.1
Host: vulnerable.com
Cookie: sessionid=abcdef12345

3.2. Использование прокси-инструментов

Инструменты, такие как Burp Suite, OWASP ZAP, Postman и Mitmproxy, позволяют перехватывать и анализировать запросы. Можно проверить, выполняется ли действие без необходимости указывать CSRF-токен.

Пример перехваченного запроса в Burp Suite:

POST /transfer HTTP/1.1
Host: bank.com
Cookie: sessionid=abcdef12345
Content-Type: application/x-www-form-urlencoded
Content-Length: 50

amount=1000&recipient=attacker&submit=Send

3.3. Проверка заголовков и токенов

При анализе запросов стоит обратить внимание на наличие Origin, Referer, а также проверять, требует ли сервер уникальный CSRF-токен в теле запроса.

Пример безопасного запроса с CSRF-токеном:

POST /transfer HTTP/1.1
Host: bank.com
Cookie: sessionid=abcdef12345
Content-Type: application/x-www-form-urlencoded
X-CSRF-Token: a1b2c3d4e5

amount=1000&recipient=attacker&submit=Send

3.4. Тестирование через HTML-формы

Можно создать тестовую форму, которая отправляет запрос к целевому сайту, и проверить, выполняется ли действие без дополнительных проверок.

<form action="https://bank.com/transfer" method="POST">
    <input type="hidden" name="amount" value="1000">
    <input type="hidden" name="recipient" value="attacker">
    <input type="submit" value="Send">
</form>

3.5. Анализ JavaScript-кода

Некоторые сайты используют JavaScript для защиты от CSRF. Можно проверить, не используются ли предсказуемые токены или слабые механизмы проверки запросов.

4. Последствия CSRF-атаки

CSRF может привести к следующим последствиям:

  • Кража средств — атака на банковские системы, переводы денег без ведома пользователя.
  • Изменение учетных данных — смена пароля, e-mail или других важных данных учетной записи.
  • Изменение настроек аккаунта — включение вредоносных функций, например, переадресация почты.
  • Удаление данных — злоумышленник может удалять файлы, учетные записи или важные записи в базе данных.
  • Подмена контактов и сообщений — изменение настроек мессенджеров и соцсетей.

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

5.1. CSRF-токены

Добавление CSRF-токенов в запросы делает атаку сложнее, так как злоумышленник не сможет предсказать или получить этот токен.
Пример CSRF-токена в форме:

<input type="hidden" name="csrf_token" value="a1b2c3d4e5">

5.2. Проверка Origin и Referer

Сервер должен проверять заголовки Origin и Referer, чтобы убедиться, что запрос действительно исходит от доверенного источника.

5.3. Ограничение сессий по IP-адресу

Связывание сессий с IP-адресом пользователя помогает предотвратить атаки с других устройств.

5.4. Использование SameSite атрибута для cookies

Настройка cookies с SameSite=Strict или SameSite=Lax предотвращает их отправку в межсайтовых запросах.

Set-Cookie: sessionid=xyz; Secure; HttpOnly; SameSite=Strict

5.5. Использование CAPTCHA

Добавление CAPTCHA перед критически важными действиями помогает предотвратить автоматизированные CSRF-атаки.

6. Обход CSRF-защиты

6.1. Обход CSRF-токенов

  • Перехват токена через XSS — внедрение вредоносного JavaScript-кода для кражи токена.
  • Использование предсказуемых токенов — генерация токенов по простым алгоритмам.
  • Реиспользование старых токенов — повторное использование ранее скомпрометированных токенов.
  • Атака через CORS — использование неправильно настроенного CORS для кражи CSRF-токена.

6.2. Обход ограничений по IP

  • Использование прокси и VPN — скрытие реального IP-адреса.
  • Эксплуатация NAT и CDN — маскировка под пользователей за NAT/CDN.
  • Фальсификация заголовков X-Forwarded-For — обман механизмов, доверяющих этому заголовку.

7. Заключение

CSRF — опасная уязвимость, которая позволяет злоумышленникам выполнять действия от имени пользователей. Регулярное тестирование безопасности помогает выявить потенциальные уязвимости и защитить пользователей от атак.

8. Где можно потренироваться?

Вы можете попрактиковаться в нахождении и эксплуатации CSRF-уязвимостей на платформе PortSwigger Web Security Academy, где представлены различные сценарии атак и защиты.(https://portswigger.net/web-security/csrf)

9. Полезные источники

Skillfactory "CSRF": https://blog.skillfactory.ru/glossary/csrf/
Хабр "Безопасность в деталях: исследование cистемы защиты от CSRF": https://habr.com/ru/companies/banki/articles/759058/