Sessão e navegador

O que é CSRF?

Por que o navegador participa

Cookies de sessão podem ser anexados automaticamente às requisições para o domínio correspondente. Uma página maliciosa pode tentar acionar uma rota de alteração de e-mail, transferência ou configuração. Sem uma defesa adicional, o servidor pode interpretar a requisição como legítima porque ela chega acompanhada da sessão da vítima.

O ataque não depende de conhecer a senha ou roubar o cookie. Ele explora a confiança que a aplicação deposita em uma requisição autenticada, sem comprovar que ela foi iniciada pela interface legítima.

Quando a ameaça é relevante

O risco é maior em aplicações que usam autenticação baseada em cookies e aceitam operações que mudam estado sem um verificador antifalsificação. Endpoints que apenas leem dados também não devem alterar estado, pois requisições GET podem ser disparadas por vários elementos do navegador.

Defesas principais

• Use tokens anti-CSRF únicos e validados no servidor para operações sensíveis.
• Configure cookies com SameSite apropriado ao fluxo da aplicação.
• Valide os cabeçalhos Origin e, como apoio, Referer.
• Exija reautenticação ou confirmação explícita para ações de alto impacto.
• Não use GET para alterar dados.
• Em APIs, exija cabeçalhos personalizados e uma política CORS restrita.

CSRF não é XSS

Em CSRF, o atacante tenta enviar uma ação válida de outro contexto. Em XSS (Cross-Site Scripting), código não confiável executa dentro da origem da aplicação. Uma vulnerabilidade XSS pode contornar várias defesas de CSRF, por isso as duas classes precisam ser tratadas em conjunto.

Referência

A OWASP detalha padrões de token, SameSite e validação de origem em seu guia de prevenção.