CSRF: O que é, como funciona e como proteger seu site contra ataques

CSRF (Cross-Site Request Forgery) é uma técnica que faz o navegador de um usuário autenticado realizar ações em um site sem o seu conhecimento explícito. O invasor não precisa saber a senha, interceptar a sessão ou acessar diretamente a conta - basta aproveitar o fato de que o navegador já considera o usuário como autenticado.

O que significa CSRF e por que essa ameaça existe

CSRF em termos simples

A CSRF explora situações em que o usuário já está autenticado em um site e o navegador armazena os dados da sessão. Por exemplo, ao acessar uma loja online ou painel corporativo sem sair da conta, o navegador continua confirmando automaticamente as solicitações para esse site.

Se o usuário, nesse período, abrir uma página maliciosa, clicar em um link perigoso ou carregar um elemento de outro site, o navegador pode enviar uma solicitação ao serviço onde ele já está autenticado - tudo isso sem que o usuário perceba qualquer ação.

O problema ocorre quando o servidor apenas verifica a existência de uma sessão ativa, sem garantir que a solicitação foi realmente iniciada pelo usuário através do próprio site.

Resumidamente, o usuário faz login, recebe uma sessão ativa e, ao visitar outra página, pode ter uma solicitação iniciada para o serviço alvo. O navegador anexa os dados de autenticação e o servidor interpreta isso como uma ação legítima do dono da conta.

O significado de Cross-Site Request Forgery

O termo completo, Cross-Site Request Forgery, descreve com precisão a essência do ataque: uma solicitação criada em um site é enviada para outro, em nome de um usuário autenticado.

É importante diferenciar o ataque CSRF da vulnerabilidade CSRF. O ataque é a tentativa de forçar o navegador a executar uma ação indesejada. A vulnerabilidade é uma falha na lógica da aplicação que permite ao servidor aceitar tal solicitação sem verificação adicional.

O navegador não está agindo incorretamente - ele apenas segue seu comportamento padrão de enviar cookies e dados de sessão conforme as configurações de segurança. O problema está na aplicação, se ela considera a sessão ativa como prova suficiente da intenção do usuário.

Assim, o CSRF não envolve necessariamente roubo de senhas ou invasão de contas. O invasor explora a autenticação já existente e tenta forçar o navegador a executar uma ação legítima, mas em um momento inadequado.

Como funciona o ataque CSRF: da página maliciosa ao pedido em nome do usuário

Por que o navegador envia cookies automaticamente

Após o login, o site geralmente cria uma sessão e a associa ao navegador por meio de um cookie. Em acessos subsequentes ao mesmo domínio, o navegador anexa esse cookie às solicitações, evitando que o usuário precise informar login e senha repetidamente.

O ataque CSRF aproveita exatamente esse comportamento. Uma página de terceiros pode tentar iniciar uma solicitação ao site onde o usuário já está autenticado. Se as condições permitirem que o navegador envie os cookies de sessão, o servidor verá essa autenticação e poderá aceitar a solicitação como legítima.

O problema central é que o cookie confirma a sessão, mas não prova que o usuário realmente quis realizar aquela ação. Se não houver verificações adicionais, o invasor pode explorar essa brecha entre autenticação e confirmação de intenção.

Exemplo de ataque CSRF

Imagine um serviço onde um usuário autenticado pode alterar configurações da conta. Se o servidor aceitar essa alteração apenas com base na sessão ativa, uma página externa pode tentar iniciar essa mesma solicitação.

Basta que o usuário acesse um site malicioso e o navegador, em segundo plano, interaja com o serviço alvo. Para o servidor, a solicitação parece proveniente de um cliente já autenticado.

O invasor nem sempre obtém acesso à resposta do servidor ou ao conteúdo da conta. No CSRF clássico, o objetivo não é ler dados alheios, mas fazer com que o sistema execute uma ação em nome da vítima.

Ações especialmente perigosas

Solicitações que alteram o estado do sistema são as mais críticas: mudar dados de contato, configurações de segurança, perfil ou ações administrativas.

O risco aumenta se essas operações não requerem confirmação extra e são executadas imediatamente após o pedido. Quanto mais privilégios tiver o usuário, maiores podem ser as consequências - um ataque CSRF em uma conta de administrador é muito mais grave.

Por isso, operações importantes não devem ser validadas apenas pela sessão ativa. O servidor precisa de outras evidências de que a solicitação foi feita por meio do próprio site e iniciada pelo usuário.

CSRF token: como diferenciar uma solicitação legítima de uma fraudulenta

O que é um CSRF token

O CSRF token é um valor adicional que o servidor espera receber junto com uma solicitação sensível. Ele é gerado de forma única para o usuário, sessão ou formulário e enviado à página responsável pela ação.

Ao enviar um formulário ou alterar configurações pelo site, o navegador devolve o token ao servidor, que só executa a operação após validar o valor recebido.

Assim, apenas a sessão ativa não basta - se o token estiver ausente ou incorreto, a solicitação será rejeitada, mesmo que o cookie de sessão seja válido.

Por que o invasor não pode enviar o token correto?

Sites de terceiros não têm acesso livre ao conteúdo de páginas de outros domínios. Eles podem tentar iniciar uma solicitação, mas normalmente não conseguem ler o token CSRF do formulário do serviço alvo para incluí-lo no pedido falso.

A diferença crucial em relação ao cookie: o navegador envia cookies de sessão automaticamente conforme suas configurações, mas o CSRF token precisa ser incluído explicitamente pela aplicação.

Se o valor do token for imprevisível e o servidor realmente o verificar, falsificar a solicitação se torna muito mais difícil. Só estar autenticado não é suficiente para o ataque funcionar.

Outras formas de proteção contra CSRF

Configurações de cookies também ajudam na proteção. O atributo SameSite limita o envio de cookies em cenários entre sites, reduzindo as chances de uma página externa explorar a sessão ativa do usuário.

O servidor pode verificar os cabeçalhos Origin ou Referer para determinar de onde veio a solicitação - uma camada extra de proteção, especialmente para operações que só devem ocorrer nas páginas do próprio serviço.

Para ações críticas, recomenda-se confirmação adicional de identidade: novo login, código de uso único ou confirmação explícita da operação. Assim, mesmo com a sessão ativa e tentativa de forjar a solicitação, a ação crítica não é automaticamente executada.

CSRF e XSS: diferenças entre os ataques

CSRF explora a confiança do site no navegador

Em ataques CSRF, o invasor se aproveita da autenticação já existente do usuário. O navegador pode enviar uma solicitação com cookies de sessão e o servidor aceitá-la como uma ação legítima do proprietário da conta.

A principal característica do CSRF é que o código malicioso não precisa ser executado dentro do site alvo - a ação pode começar em uma página externa que tenta fazer o navegador se comunicar com outro serviço em nome do usuário.

XSS explora a confiança do usuário no site

XSS (Cross-Site Scripting) funciona de modo diferente. O problema surge quando o site permite a inserção e execução de JavaScript não autorizado em seu próprio contexto.

Quando esse script é executado, ele tem os mesmos privilégios do site e pode alterar conteúdos, interceptar ações do usuário ou fazer solicitações em seu nome, dependendo do tipo de vulnerabilidade.

No CSRF, o invasor normalmente não acessa o conteúdo da página do site alvo - seu objetivo é apenas forçar o navegador a enviar uma solicitação. Já no XSS, o código malicioso é executado dentro do site, ampliando em muito as possibilidades do ataque.

Por que uma proteção não substitui a outra

Tokens CSRF protegem contra falsificação de solicitações externas, mas não contra XSS. Se um invasor consegue rodar JavaScript dentro do site vulnerável, o script pode interagir com o próprio sistema de proteção.

O inverso também é verdadeiro: proteção contra XSS (escapando dados, filtrando entradas, usando Content Security Policy) não substitui o uso de tokens CSRF e a configuração de SameSite em cookies.

Portanto, CSRF e XSS pertencem a classes diferentes de vulnerabilidades web. Podem ter consequências semelhantes, mas usam mecanismos distintos e exigem defesas específicas.

Como proteger seu site de ataques CSRF

Verifique todas as solicitações que alteram dados

A proteção começa com a lógica correta da aplicação. Solicitações que modificam dados do usuário ou do sistema não devem ser executadas apenas porque o navegador enviou um cookie de sessão válido.

É fundamental não usar GET para operações que alteram algo - esse método deve ser reservado para consultas. Alterações, exclusões e transações devem ser feitas via POST, PUT, PATCH ou DELETE, sempre com validação adicional da solicitação.

Mas só escolher o método HTTP correto não basta. Se o servidor ainda confiar apenas na sessão, a vulnerabilidade CSRF pode persistir. Por isso, requisições sensíveis devem ser verificadas quanto à origem ou conter um valor de confirmação.

Implemente tokens CSRF e cookies SameSite

Uma das principais defesas é o uso de tokens CSRF. O servidor gera um valor imprevisível e espera recebê-lo junto com a solicitação. Uma página externa normalmente não consegue saber o token correto, então, mesmo com sessão ativa, o pedido falso será rejeitado.

O atributo SameSite nos cookies adiciona outra camada de proteção, restringindo o envio de cookies em cenários entre sites e reduzindo as chances de o navegador anexar dados de autenticação a solicitações iniciadas por terceiros.

Tokens CSRF e SameSite devem ser vistos como camadas complementares e não soluções exclusivas. O token legitima a solicitação, enquanto SameSite limita o envio automático de cookies entre domínios.

O CSRF é apenas uma entre várias vulnerabilidades web. Por exemplo, na SQL Injection, o invasor visa manipular as consultas ao banco de dados, não apenas o navegador. Confira detalhes neste material especializado.

Verificações adicionais para operações críticas

Para ações de maior impacto, apenas o token CSRF pode não bastar. Mudança de senha, definição de métodos de recuperação, gerenciamento de permissões e outras operações críticas devem exigir confirmação extra de identidade.

Isso pode incluir novo login, código de uso único ou confirmação explícita. Assim, mesmo que uma solicitação seja enviada de modo indevido, ela não resultará em mudanças sérias sem a devida validação.

O servidor também pode analisar os cabeçalhos Origin e Referer para identificar a origem da solicitação, recusando acessos de fontes inesperadas. Essas verificações são complementares e não devem ser a única linha de defesa.

A segurança robusta combina múltiplas camadas: métodos HTTP corretos, tokens CSRF, cookies SameSite, verificação da origem das solicitações e confirmação extra para ações críticas.

Conclusão

O ataque CSRF não depende da quebra de senhas, mas da confiança do site no navegador já autenticado. Se o servidor considera a sessão ativa como prova suficiente para executar ações, uma página externa pode tentar iniciar solicitações em nome do usuário.

A defesa principal envolve tokens CSRF, que permitem ao servidor verificar se a solicitação foi realmente gerada pelo próprio aplicativo. Outras medidas incluem cookies SameSite, verificação de Origin e Referer, uso adequado de métodos HTTP e confirmação adicional para operações críticas.

O princípio para o desenvolvedor é simples: uma sessão válida não garante que o usuário realmente iniciou a ação. Ao alterar dados, o servidor deve sempre validar a legitimidade da solicitação.