Hacker News Digest

CSRF — атака «сбитого заместителя»: злоумышленник заставляет браузер отправить запрос на целевой сайт с авторизацией жертвы через куки.
Пример: скрытая форма на attacker.example переводит деньги с example.com.

Защита нужна всем, кто использует cookie-аутентификацию. Это не про полный доступ злоумышленника, а про блокировку подделанных запросов.

Почему браузеры разрешают?

Из-за обратной совместимости и SSO-потоков; отключение «сторонних» кук ломает авторизацию.

same-site ≠ same-origin

• https://app.example.com и https://marketing.example.com — same-site, но разные origin.
• HTTP ↔ HTTPS — разные trust-уровни; схема важна.
• Куки пока схему не учитывают (кроме Chrome с 2020).
• Sec-Fetch-Site и Fetch-спецификация считают HTTP и HTTPS разными сайтами.
• HSTS помогает закрыть HTTP→HTTPS CSRF.

Защита

Токены

• Double-submit: случайное значение в cookie и в теле/параметре.
• Synchronized tokens: значение хранится на сервере.
• Проблема «cookie tossing» — чужой origin может подложить куку.
  • Решение: префикс __Host- или подпись токена с привязкой к пользователю.
• Подпись без привязки к пользователю бесполезна: злоумышленник может взять свою пару «кука-токен».

SameSite cookies

• SameSite=Lax/Strict блокирует отправку кук на cross-site POST.
• Не защищает от GET-CSRF при Lax.
• Не работает для «сторонних» POST, если нужен SSO-обход.

Origin/Referer

• Проверка заголовков Origin/Referer; ломается при их отсутствии.

Fetch Metadata + Sec-Fetch-*

• Sec-Fetch-Site, Sec-Fetch-Mode, Sec-Fetch-Dest позволяют серверу отвергать подозрительные запросы.
• Пока не везде поддерживается.

SameSite + токены

• SameSite закрывает большинство случаев, токен — оставшиеся edge-case.
• Удобно, но нужно помнить про SSO-исключения.

Итого

• Используйте SameSite=Lax + CSRF-токен.
• Для критичных действий — SameSite=Strict или явная проверка Origin.
• Учитывайте HTTP→HTTPS и cookie-tossing.