Подделка межсайтовых запросов (CSRF)

Браузер автоматически прикладывает cookie к запросам на ваш домен (классическая схема до SameSite). Значит, любой сайт в интернете может инициировать POST на ваш банковский/админский эндпоинт — и сервер увидит «настоящую» сессию.

Проблему описали в начале 2000-х (исследования Zeller, Felten и др.); к 2008 году CSRF прочно вошёл в OWASP Top 10. Сегодня A01:2021 «Broken Access Control» включает и эти сценарии.

Вы залогинены в панели хостинга. Открываете письмо «ваш счёт» — внутри скрытая форма <form action="https://panel.example/email" method="POST"><input name="email" value="evil@mail">. Если панель не проверяет источник запроса, e-mail аккаунта меняется, дальше — сброс пароля.

В финансовом секторе классика — «одноклик» перевод или смена лимитов: пользователь заходит на форум, картинка или iframe триггерит POST /transfer. Суммы копеечные, но в цикле и на тысяче пользователей ущерб значимый.

Исследователь Адриан Пастернак (Adrian Pastor) показал, что через CSRF можно выгрузить список контактов из Gmail. Жертва заходила на вредоносную страницу, оставаясь залогиненной в Gmail, — и браузер сам отдавал запрос с настоящей сессией. Google в итоге усилил защиту и стал требовать подтверждение для чувствительных действий.

Тот же класс атак применяли против банковских и хостинг-панелей: смена e-mail, получение доступа к API-ключам, «тихая» постановка переадресации. Показательно, что пароль и сервер при этом не были скомпрометированы — слабым звеном оказалась логика доверия браузера.

Заголовки Referer/Origin можно «обрезать» политиками браузера, а пустой Referer — не гарантия безопасности. Неаутентифицированные переходы из мессенджеров и PDF-ридеров часто не несут Origin.

• Anti-CSRF токены (Synchronizer token / double submit) — стандарт для state-changing запросов.
• SameSite=Lax/Strict для сессионных cookie (поддерживается всеми современными браузерами).
• Повторное подтверждение критичных операций: ввод пароля, SMS/2FA, аппаратный ключ.
• Не использовать GET для изменяющих действий — это убивает целый класс атак и путаницу с кэшированием.
• Custom headers (X-Requested-With) как дополнительный барьер — не единственная защита.

При наличии XSS CSRF-токен крадётся вместе со страницей. Поэтому защита многослойная: сначала — нет исполнения чужого кода, потом — токены и SameSite.