Что такое CSRF уязвимость?

Что такое CSRF уязвимость?

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

Как работает CSRF атака

Представь, что ты логин в свой банк и не закрыл вкладку:

1. Ты открываешь новую вкладку и заходишь на вредоносный сайт
2. На этом сайте есть скрытая форма или картинка, которая делает запрос к твоему банку
3. Банк видит запрос от твоего браузера (cookies есть) и выполняет действие
4. Деньги переведены, а ты даже не знаешь, что произошло

<!-- Вредоносный сайт содержит что-то типа: -->
<img src="https://bank.com/transfer?to=attacker&amount=1000" />

<!-- Или скрытую форму: -->
<form action="https://bank.com/transfer" method="POST" style="display: none;">
  <input type="hidden" name="to" value="attacker" />
  <input type="hidden" name="amount" value="1000" />
</form>

Почему это работает?

Браузер автоматически отправляет cookies вместе с каждым запросом на домен банка. Банк не может отличить легитимный запрос от пользователя от запроса со вредоносного сайта, если нет дополнительной защиты.

Как защищаться?

1. CSRF токены (SameSite cookies)

Сервер генерирует уникальный токен для каждой сессии и требует его в POST-запросах:

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="abc123xyz" />
  <input type="text" name="amount" />
  <button type="submit">Отправить</button>
</form>

Вредоносный сайт не может узнать значение этого токена (благодаря Same-Origin Policy), поэтому атака не сработает.

2. SameSite флаг для cookies

// На сервере устанавливаешь cookies так:
Set-Cookie: session=xyz; SameSite=Strict; Path=/; HttpOnly

SameSite=Strict — cookies отправляются только на запросы от того же сайта. SameSite=Lax — более мягко, разрешает cookies при переходе по ссылке.

3. Проверка Origin/Referer заголовков

Сервер может проверять, откуда пришел запрос:

// На сервере (Node.js/Express)
app.post("/transfer", (req, res) => {
  const referer = req.get("Referer");
  const origin = req.get("Origin");
  
  if (!origin.includes("bank.com")) {
    return res.status(403).send("CSRF атака!");
  }
  // Процесс перевода...
});

Пример безопасного POST запроса с фронта

// Получаешь CSRF токен из meta тега
const token = document.querySelector("meta[name=csrf-token]").content;

// Отправляешь с токеном
fetch("/api/transfer", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-CSRF-Token": token
  },
  body: JSON.stringify({
    to: "recipient",
    amount: 100
  })
});

Практический совет для фронтендера

Когда пишешь приложение:

• Всегда используй SameSite=Strict для cookies аутентификации
• Добавляй CSRF токены в формы (особенно в критические действия)
• Никогда не передавай sensitive данные через GET параметры
• Используй https везде
• Провяляй CORS корректно (не открывай все домены)

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