Cross-Site Request Forgery (CSRF)

Falsificação de solicitação entre sites (CSRF) induz o navegador de um usuário autenticado a fazer solicitações não autorizadas a uma aplicação web. O navegador envia cookies automaticamente com as solicitações, portanto o servidor não consegue distinguir solicitações legítimas de solicitações forjadas sem medidas adicionais.

Cenário:

1. A vítima está conectada a bank.com (cookie de sessão no navegador)
2. A vítima acessa a página do invasor com: <img src="https://bank.com/transfer?to=attacker&amount=1000">
3. O navegador envia a solicitação GET com o cookie de bank.com anexado
4. O banco processa a transferência

O CSRF com POST exige um formulário:

A principal defesa é um token CSRF: um valor aleatório, secreto e específico da sessão (ou da solicitação), incorporado aos formulários. O servidor valida o token em todas as solicitações que alteram o estado. Um invasor em outro domínio não consegue ler o token (política de mesma origem).

SameSite=Strict: o cookie não é enviado com solicitações entre sites. SameSite=Lax: o cookie é enviado com navegações seguras de nível superior (links), mas não com POST de outros sites. Os navegadores modernos usam Lax por padrão, reduzindo significativamente o risco de CSRF.

Uma alternativa ao armazenamento do token no servidor: defina um cookie CSRF aleatório e exija que ele também seja enviado como parâmetro da solicitação. Um invasor não consegue ler o cookie (mesma origem), portanto não consegue fazer com que ele corresponda ao valor nos dados do formulário.

Para solicitações AJAX, exigir um cabeçalho personalizado (por exemplo, X-Requested-With: XMLHttpRequest) fornece proteção contra CSRF porque os navegadores impedem que scripts entre origens definam cabeçalhos arbitrários (o CORS impõe essa restrição).

Os tokens CSRF falham se:

• Houver XSS — o invasor poderá ler o token por meio de JavaScript
• O token for vazado na URL (cabeçalho Referer)
• O token for previsível ou reutilizado
• O CORS estiver configurado incorretamente para permitir a origem do invasor

Etapas do teste:

1. Identifique as solicitações que alteram o estado (POST, PUT, DELETE)
2. Remova ou modifique o token CSRF e reenvie a solicitação
3. Crie um envio de formulário entre origens e verifique se ele é bem-sucedido
4. Verifique o atributo SameSite nos cookies de sessão

As APIs REST que usam JSON geralmente são isentas de CSRF se:

• Exigirem Content-Type: application/json (os formulários HTML não podem definir esse valor)
• Usarem autenticação baseada em token (cabeçalho Authorization, não cookies)

Mas as APIs que aceitam cookies ainda precisam implementar proteção contra CSRF.

Com SameSite=Lax como padrão no Chrome, Firefox e Safari, muitos ataques tradicionais de CSRF são bloqueados. No entanto, ataques a subdomínios e determinados padrões de navegação ainda podem contornar o Lax. Combine SameSite com tokens CSRF para obter uma defesa robusta.

Qual é a principal defesa contra ataques de CSRF em aplicações web?

O CSRF explora o envio automático de cookies pelo navegador para forjar solicitações autenticadas a partir de sites maliciosos. Principal defesa: tokens CSRF validados no servidor. Secundária: atributo de cookie SameSite=Strict/Lax. APIs que usam autenticação por token em cabeçalhos (não cookies) são naturalmente resistentes a CSRF. Combine as defesas; o XSS pode contornar tokens CSRF se estiver presente.