O CSRF (Cross-Site Request Forgery), ou Falsificação de Solicitação Entre Sites, é um ataque cibernético que força o navegador de um usuário a executar ações indesejadas em um site onde ele já está logado e autenticado. O ataque funciona enganando o navegador para que ele anexe automaticamente os cookies de sessão ativos da vítima a uma requisição HTTP forjada, fazendo com que o servidor web acredite que a ação foi solicitada legitimamente pelo próprio usuário.
Principais Aprendizados
- O CSRF não rouba dados diretamente, mas força o usuário a executar ações prejudiciais, como transferir fundos ou alterar senhas.
- A vulnerabilidade ocorre porque os navegadores da web enviam cookies de sessão automaticamente para o domínio de origem, independentemente de onde a requisição foi gerada.
- A defesa mais eficaz envolve o uso de Tokens Anti-CSRF exclusivos por sessão e a configuração do atributo SameSite nos cookies.
Como o ataque CSRF funciona na prática?
Para que um ataque CSRF seja bem-sucedido, três condições precisam ser atendidas simultaneamente. Primeiro, deve haver uma ação relevante na aplicação, como a alteração de um e-mail de recuperação ou uma transação financeira. Segundo, o aplicativo deve depender exclusivamente de cookies de sessão para rastrear e validar a identidade do usuário. Por fim, os parâmetros da requisição HTTP que executam a ação devem ser previsíveis para o atacante.
Quando essas falhas se alinham, o atacante cria um link ou uma página web contendo uma requisição HTTP oculta. Se a vítima clicar nesse link enquanto estiver com a sessão aberta no site vulnerável, o navegador enviará a requisição maliciosa junto com os cookies de autenticação. É por isso que o CSRF é frequentemente citado em relatórios de segurança e já foi uma presença constante no OWASP Top 10, o guia definitivo de vulnerabilidades web.
O papel crítico dos Cookies de Sessão
O grande vilão (ou facilitador) do CSRF é o comportamento padrão dos navegadores web em relação às chamadas credenciais de ambiente (ambient credentials). Historicamente, navegadores como Chrome, Firefox e Edge foram programados para anexar automaticamente os cookies associados a um domínio sempre que uma requisição é feita para esse domínio, independentemente de a requisição ter se originado do próprio site ou de uma aba cruzada (cross-site).
Se você está logado no seu banco e abre uma nova aba para acessar um blog malicioso, esse blog pode conter um formulário invisível que faz um POST para o site do banco. O seu navegador, obedientemente, anexa o cookie de sessão do banco a esse POST. O servidor do banco recebe a requisição, vê um cookie válido e executa a transferência. Para entender a fundo como os navegadores gerenciam essa mecânica, a documentação da Mozilla Developer Network sobre cookies é uma das fontes mais respeitadas cientificamente no meio do desenvolvimento.
Exemplo prático: A transferência bancária forjada
Imagine que o site do seu banco permita transferências via requisições GET (uma péssima prática, mas útil para o exemplo) no formato: http://banco.com/transferir?conta=123&valor=1000. Um atacante pode colocar uma tag de imagem invisível em um fórum público: <img src="http://banco.com/transferir?conta=HACKER&valor=1000" width="0" height="0">.
Ao carregar a página do fórum, o seu navegador tenta carregar a "imagem". Para isso, ele faz uma requisição GET para a URL do banco. Como você está logado, o cookie vai junto. O banco processa a transferência e você perde o dinheiro, sem nem perceber. Diferente de quando um script malicioso (XSS) é injetado para roubar dados ativamente, o CSRF usa a própria infraestrutura legítima contra você.
Como proteger sua aplicação contra o CSRF?
Segundo estatísticas de empresas de cibersegurança, as falhas de CSRF caíram drasticamente na última década graças à adoção de frameworks modernos, mas ainda aparecem constantemente quando realizamos um teste de invasão em sistemas legados. A mitigação exige uma abordagem em camadas.
1. Uso de Tokens Anti-CSRF (Synchronizer Token Pattern)
A defesa mais robusta recomendada pela OWASP é a implementação de tokens anti-CSRF. Trata-se de uma string aleatória, criptograficamente forte e exclusiva para a sessão do usuário. O servidor gera esse token e o envia para o cliente. Em cada requisição que altera o estado do sistema (POST, PUT, DELETE), o cliente deve enviar esse token de volta (geralmente em um campo oculto do formulário ou no cabeçalho HTTP). Como o atacante não consegue ler o token devido à Política de Mesma Origem (SOP), ele não consegue forjar uma requisição válida. A OWASP CSRF Prevention Cheat Sheet detalha matematicamente a força necessária para esses tokens.
2. Configuração do Atributo SameSite
O atributo SameSite nos cookies de sessão é uma diretiva moderna que diz ao navegador se o cookie deve ou não ser enviado em requisições cross-site. Configurar o cookie como SameSite=Lax (que se tornou o padrão em muitos navegadores) impede que o cookie seja enviado em requisições POST de terceiros. Configurar como SameSite=Strict garante que o cookie só será enviado se a requisição se originar exatamente do mesmo site, blindando completamente o usuário contra o CSRF.
Perguntas Frequentes
Qual a diferença entre CSRF e XSS?
Enquanto o XSS (Cross-Site Scripting) envolve a injeção de código JavaScript malicioso no navegador da vítima para roubar dados ou sequestrar sessões, o CSRF não injeta código. O CSRF apenas se aproveita de uma sessão já autenticada para enviar requisições forjadas. O XSS explora a confiança do usuário no site; o CSRF explora a confiança do site no navegador do usuário.
Um antivírus consegue bloquear um ataque CSRF?
Não. Um ataque CSRF ocorre no nível do protocolo HTTP e das requisições web. Como o tráfego parece ser uma solicitação legítima feita pelo próprio usuário através do navegador, antivírus tradicionais não conseguem detectar a anomalia. A proteção deve ser implementada no código da aplicação web.
O uso de HTTPS impede o CSRF?
Não. O HTTPS criptografa os dados em trânsito, protegendo-os contra interceptação (ataques Man-in-the-Middle). No entanto, o HTTPS não impede que o navegador anexe cookies válidos a uma requisição forjada. Um ataque CSRF funciona perfeitamente mesmo em conexões seguras por HTTPS.
0 Comentários