XSS Moderno: DOM, Stored e Reflected com Exemplos Reais em Ambiente de Teste

Em 2025 o relatorio da HackerOne registrou XSS como o segundo bug mais reportado em bug bounties publicos, com mediana de USD 750 por achado e picos de USD 20 mil em alvos enterprise. A familia segue viva porque navegadores evoluiram, mas pipelines de frontend ainda concatenam strings em innerHTML sem cerimonia. A equipe Basilisk abre um lab com tres aplicacoes propositalmente furadas, registra requisicoes no Burp Suite Community 2026.4 e mostra cada vetor com payload, contexto e patch. Antes de seguir, garanta que seu lab esta isolado conforme Pentest Web do Zero: Montando um Lab Seguro com DVWA, Juice Shop e Burp Suite, porque rodar payloads contra terceiros sem autorizacao escrita continua sendo crime no Brasil sob a Lei 12.737/2012.

Reflected XSS aparece quando a entrada do usuario volta na resposta HTTP sem codificacao adequada, geralmente via querystring ou formulario GET. No nosso lab uma busca em /search?q= concatena o termo dentro de um

, entao o payload classico

Stored XSS e o mais perigoso porque persiste no banco e atinge qualquer visitante. No DVWA setamos o nivel medium, enviamos no campo de comentario o payload e observamos o webhook receber sessoes de moderadores em segundos. Em apps reais a superficie inclui Markdown renderers, templates de email, exports CSV abertos em Excel e ate metadados EXIF lidos por um dashboard interno, conforme detalhamos em Higiene de Metadados: Limpando EXIF, PDF e Office antes de Publicar. A unica defesa robusta combina sanitizacao no input com escape no output, nunca um ou outro isolado.

DOM-based XSS acontece inteiramente no cliente, sem que o payload toque o servidor. O classico location.hash sendo jogado em document.write ainda existe em widgets legados de chat e em SPAs que usam React dangerouslySetInnerHTML com dados do hash. No lab usamos o desafio nivel 1 do Google XSS Game adaptado, e a chave para encontrar sinks e abrir o DevTools, marcar 'Pause on exceptions' e usar a extensao DOM Invader do Burp. O fluxo de triagem segue o mesmo principio metodologico de SQL Injection na Pratica: Explorando, Detectando e Mitigando em Lab Controlado: identificar source, rastrear ate o sink, validar com payload minimo.

Mitigacao moderna nao e mais sobre filtrar < e >. Content Security Policy nivel 3 com nonce por requisicao bloqueia injecao inline mesmo quando o atacante consegue colocar HTML na pagina, desde que voce nao caia na armadilha de adicionar 'unsafe-inline' como fallback. Trusted Types, suportado em Chromium desde 83 e finalmente em Firefox 135, transforma atribuicoes a innerHTML em type error a menos que passem por uma policy registrada. Combine com DOMPurify 3.2 para sanitizar HTML rico e voce reduz a superficie em 90% segundo benchmarks do Google. Para ambientes com APIs internas, alinhe com AppSec Shift-Left: SAST, SCA e Secrets Scanning sem Travar o Time e rode Semgrep com a regra javascript.lang.security.audit.xss em cada PR.

O takeaway pratico: monte hoje um lab com DVWA, Juice Shop e um Next.js minimo, replique os tres vetores ate conseguir um popup em cada, depois aplique CSP com nonce, Trusted Types e DOMPurify e reexecute os mesmos payloads. Se ainda dispararem, ajuste a policy ate quebrar. Documente cada iteracao num runbook proprio porque relatorios bons de XSS no programa de bounty do Mercado Livre, GitHub ou Shopify exigem reproducao em uma frase, impacto comprovado e patch sugerido. Estude tambem Threat Modeling com STRIDE em Sprints: Exemplo Completo de Microservico para classificar cada injecao dentro do dominio Tampering+Elevation antes de subir o ticket, isso muda a triagem para P1 mais rapido.