CSRF

↑ 7.3 Безопасность фронтенда · ← Предыдущая · → Следующая

Желательно~3 мин чтенияУровень: senior

Зачем это на собесе

Атака на cookie-аутентификацию; проверяют, понимаете ли вы SameSite и токены.

Суть

Cross-Site Request Forgery: чужой сайт заставляет браузер пользователя отправить запрос на ваш сайт. Браузер сам прикладывает cookie, и действие выполняется от имени жертвы.

<!-- на evil.com -->
<form action="https://bank.com/transfer" method="POST">
  <input name="to" value="attacker"><input name="sum" value="1000">
</form>
<script>document.forms[0].submit()</script>

Защита

Механизм	Описание
SameSite cookie	Lax (по умолчанию в браузерах) и Strict не отправляют cookie при кросс-сайтовых запросах
CSRF-токен	случайное значение в форме или заголовке, проверяется сервером
Double-submit cookie	токен в cookie и в заголовке должны совпасть
Проверка Origin/Referer	сервер отвергает чужие источники
Кастомный заголовок	простые формы не могут его поставить без CORS-preflight
Bearer-токен в заголовке	браузер сам не подставляет, CSRF неактуален (но есть XSS-риск)

axios.defaults.xsrfCookieName = 'XSRF-TOKEN'
axios.defaults.xsrfHeaderName = 'X-XSRF-TOKEN'
axios.defaults.withCredentials = true

Нюансы

• GET-запросы не должны менять состояние;
• SameSite=None требует Secure, а значит нужны токены;
• CORS сам по себе от CSRF не защищает (запрос всё равно уходит);
• поддомены считаются одним «сайтом» (site) для SameSite.

Вопросы с ответами

Чем CSRF отличается от XSS?

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

Спасёт ли SameSite=Lax?

Защитит от большинства кросс-сайтовых POST. Но для чувствительных операций всё равно нужны токены, а GET-запросы не должны менять данные.