CSRF: Proteja sua aplicação contra ataques de falsificação de requisição

Entenda o que é um ataque CSRF e como proteger sua aplicação

Imagine que você está logado no site do seu banco e, sem perceber, clica em um link malicioso recebido por e-mail. Esse simples clique pode disparar uma requisição para transferir dinheiro da sua conta. Como você já está autenticado, o banco pode interpretar essa solicitação como legítima e executá-la.

Esse é um exemplo clássico de um ataque CSRF (Cross-Site Request Forgery).

Como funciona um ataque CSRF?

O ataque ocorre quando um invasor consegue induzir um usuário autenticado a executar uma ação indesejada em uma aplicação confiável. O processo geralmente acontece da seguinte forma:

• O usuário faz login em um site confiável, como um banco, uma rede social ou um portal de notícias.

• Sem encerrar a sessão, ele acessa um site malicioso ou clica em um link enviado pelo atacante.

• Esse site envia automaticamente uma requisição para a aplicação legítima utilizando os cookies de autenticação do usuário.

• Como os cookies de sessão são enviados automaticamente pelo navegador, a aplicação interpreta a requisição como se tivesse sido realizada pelo próprio usuário.

Se não houver mecanismos de proteção, ações como alterar senhas, modificar dados cadastrais ou realizar transações podem ser executadas sem o consentimento da vítima.

Como proteger sua aplicação contra CSRF?

1. Utilize Tokens CSRF (Anti-CSRF Tokens)

A forma mais eficaz de prevenir ataques CSRF é implementar tokens de segurança.

Cada formulário ou requisição que altera informações deve conter um token único, aleatório e imprevisível. Antes de executar qualquer operação, o servidor valida esse token. Caso ele seja inválido ou inexistente, a requisição é rejeitada.

Essa é a principal camada de proteção contra esse tipo de ataque.

2. Utilize cabeçalhos HTTP customizados

Quando utilizar AJAX ou a API Fetch, envie um cabeçalho personalizado juntamente com a requisição.

Como navegadores não permitem que sites de terceiros adicionem esses cabeçalhos em requisições comuns, eles funcionam como uma camada adicional de segurança.

3. Configure corretamente os cookies com SameSite

Os cookies de sessão devem utilizar o atributo SameSite, reduzindo significativamente o risco de envio automático em requisições originadas de outros domínios.

session_set_cookie_params([
    'lifetime' => 3600,
    'path' => '/',
    'domain' => '.seudominio.com',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Strict' // ou 'Lax'
]);

Sempre que possível, utilize também os atributos Secure e HttpOnly para aumentar a proteção da sessão.

4. Como funciona o atributo SameSite?

O atributo SameSite define quando os cookies de uma aplicação podem ser enviados pelo navegador em requisições originadas de outros sites. Ele foi criado justamente para reduzir o risco de ataques CSRF, impedindo que cookies de autenticação sejam enviados automaticamente em cenários de navegação entre domínios.

Existem três modos de configuração:

SameSite=Strict

É a opção mais segura.

O navegador nunca enviará o cookie quando a requisição tiver origem em outro site, mesmo que o usuário clique em um link para acessar sua aplicação.

Exemplo:

• O usuário está autenticado em portal.com.

• Ele recebe um link em um e-mail ou acessa um site malicioso.

• Esse site tenta enviar uma requisição para portal.com.

• Como o cookie não é enviado, a aplicação identifica que não há uma sessão autenticada e bloqueia a ação.

Quando utilizar: sistemas bancários, painéis administrativos e aplicações que exigem o máximo de segurança.

---

SameSite=Lax

É o modo recomendado para a maioria das aplicações web.

Nesse modo, os cookies não são enviados em requisições automáticas, como formulários ocultos, requisições POST, iframe ou imagens provenientes de outros domínios. Porém, eles são enviados quando o usuário acessa o site clicando em um link comum, preservando uma boa experiência de navegação.

Exemplo:

• O usuário clica em um link para acessar uma notícia do seu portal.

• O cookie de sessão é enviado normalmente e o usuário continua autenticado.

• Porém, se um site malicioso tentar enviar um formulário oculto (POST) para alterar dados da conta, o navegador não enviará o cookie da sessão.

Esse comportamento bloqueia a maioria dos ataques CSRF sem prejudicar a navegação.

---

SameSite=None

Permite que os cookies sejam enviados em todas as requisições, inclusive entre domínios diferentes.

Essa configuração só deve ser utilizada quando realmente necessária, como em integrações com serviços externos, autenticação federada (SSO) ou aplicações incorporadas em iframe.

Por questões de segurança, sempre que SameSite=None for utilizado, o cookie deve obrigatoriamente possuir o atributo Secure, ou seja, ser transmitido apenas por conexões HTTPS.

---

Comparativo

Configuração	Cookies enviados em outros sites?	Nível de proteção
Strict	Nunca	⭐⭐⭐⭐⭐ Muito alto
Lax	Apenas em navegação por links	⭐⭐⭐⭐ Alto
None	Sempre	⭐ Baixo (usar somente quando necessário)

Exemplo em PHP

session_set_cookie_params([
    'lifetime' => 3600,
    'path' => '/',
    'domain' => '.seudominio.com',
    'secure' => true,
    'httponly' => true,
    'samesite' => 'Strict' // ou 'Lax'
]);

Na maioria dos projetos, SameSite=Lax oferece um excelente equilíbrio entre segurança e usabilidade. Já aplicações que manipulam informações altamente sensíveis, como sistemas financeiros ou painéis administrativos, podem optar por SameSite=Strict, desde que a experiência do usuário não seja comprometida.

5.. Valide os cabeçalhos Origin e Referer

Outra boa prática consiste em verificar se a requisição realmente foi originada pelo seu domínio.

$allowedOrigins = ['https://seudominio.com'];

if (!in_array($_SERVER['HTTP_ORIGIN'] ?? '', $allowedOrigins)) {
    die('Requisição bloqueada');
}

Embora essa técnica não substitua os tokens CSRF, ela adiciona uma camada extra de defesa.

Conclusão

A proteção contra ataques CSRF não é apenas uma recomendação de segurança: ela é indispensável em qualquer aplicação web que trabalha com autenticação de usuários.

A combinação de tokens CSRF, configuração adequada de cookies (SameSite, Secure e HttpOnly), validação dos cabeçalhos Origin e Referer e boas práticas de desenvolvimento reduz significativamente a superfície de ataque da aplicação.

 

Lembre-se: segurança não é um custo. É um investimento na confiabilidade da sua aplicação e na proteção dos seus usuários.