CSRF

CSRF (Cross-Site Request Forgery) é um ataque em que um site malicioso faz o navegador da vítima emitir uma requisição autenticada contra um site alvo, aproveitando os cookies que o navegador anexa automaticamente.

Exemplo clássico: você está logado em bank.example.com. Você visita evil.example, que contém <img src="https://bank.example.com/transfer?to=attacker&amount=1000" />. Seu navegador diligentemente envia a requisição com seus cookies de sessão bancária. O banco, incapaz de distinguir a origem legítima, processa a transferência.

Defesas modernas:

• Atributo SameSite do cookie (padrão Lax em navegadores modernos) — bloqueia cookies de requisições POST cross-origin.
• Tokens CSRF — tokens aleatórios emitidos pelo servidor incluídos em formulários, verificados no envio. Padrão do setor por décadas.
• Validação de cabeçalhos Origin/Referer — defesa em profundidade.
• Autenticação por token Bearer (em cabeçalhos, não cookies) — imune a CSRF por padrão.

Frameworks modernos (Django, Rails, Spring) entregam proteção CSRF habilitada por padrão. A mudança de cookie padrão-Lax de 2020 eliminou efetivamente o CSRF para a maioria dos aplicativos modernos sem nenhuma alteração de código.

Exemplo prático

Uma vulnerabilidade de 2008 em muitos roteadores domésticos ilustra o ataque clássico. A interface de administração do roteador ficava em http://192.168.1.1/, usava cookies de autenticação básica e expunha um formulário como POST /apply.cgi?dns=... para alterar o servidor DNS. Um atacante controlava um site separado que incluía um formulário invisível de envio automático apontando para essa URL. Um usuário logado visitando a página maliciosa teria seu navegador postando silenciosamente o formulário ao roteador, com os cookies de autenticação anexados automaticamente, e o DNS seria substituído pelo do atacante. Da perspectiva do roteador, cada requisição parecia legítima. A solução que o setor adotou: adicionar um token CSRF por sessão ao formulário, validá-lo no envio e rejeitar requisições onde o token esteja ausente ou incorreto. Uma segunda solução chegou com os cookies SameSite=Lax no Chrome 80 (2020) — o navegador para de enviar cookies em POSTs cross-site, derrotando o ataque na camada de cookie independentemente das verificações do lado do servidor.

Quando e por que isso importa

CSRF importa sempre que um aplicativo autentica usuários via cookies que são anexados automaticamente pelo navegador — que é a maioria dos aplicativos web legados e muitos modernos. O erro é supor que “somos uma API, CSRF não se aplica”: se a API usa cookies de sessão (em vez de tokens bearer) e aceita POSTs codificados em formulário ou JSON simples sem preflight, ela é vulnerável. O segundo erro é depender exclusivamente do cabeçalho Referer — muitos proxies corporativos e ferramentas de privacidade o removem, quebrando usuários legítimos. O mínimo moderno para um aplicativo baseado em cookies: defina SameSite=Lax (ou Strict para endpoints sensíveis) em todos os cookies de autenticação, valide um token CSRF em cada requisição que altera estado e rejeite requisições com cabeçalhos Origin incompatíveis em endpoints JSON. Para novas APIs, mude completamente para autenticação por token bearer via cabeçalho Authorization e a superfície de ataque desaparece. Referência: OWASP — Cross-Site Request Forgery.

O padrão de cookie de envio duplo: quando um backend não pode armazenar estado por sessão, o token CSRF pode ser emitido via cookie e também ser exigido em um cabeçalho de requisição personalizado. O navegador anexa automaticamente o cookie em cada requisição, mas sites cross-origin não podem ler seu valor para copiá-lo no cabeçalho — a política de mesma origem bloqueia a leitura. O servidor compara os dois e rejeita incompatibilidades. Esta é a técnica que a maioria dos frameworks modernos de single-page-app (Angular, configuração padrão do Axios) usa para defesa CSRF em APIs JSON.

Por que o CSRF está cada vez mais irrelevante: a combinação de padrões SameSite=Lax (Chrome 80, 2020), autenticação por token bearer e preflight CORS em requisições não simples reduziu a superfície de ataque prática a endpoints legados codificados em formulário que ainda dependem de cookies. Para novas APIs construídas hoje, optar por não usar cookies e usar cabeçalhos Authorization: Bearer <token> elimina o CSRF sem cerimônia. A classificação de risco do OWASP removeu o CSRF da lista Top 10 em 2017 por causa de quão generalizadas as defesas estruturais haviam se tornado. Referência: OWASP CSRF Prevention Cheat Sheet.