XSS Cheat Sheet: Um guia orientado por pesquisas com integração Penligent em um clique

Resumo

O XSS (Cross-site scripting) continua sendo uma das vulnerabilidades mais comuns e perigosas da Web. As modernas estruturas de front-end, os SPAs (aplicativos de página única) e os ricos ecossistemas de scripts de terceiros aumentam as oportunidades e a complexidade. Este artigo mescla o OWASP XSS Prevention Cheat Sheet com pesquisas acadêmicas e do setor recentes, formando uma estratégia de defesa em camadas: codificação contextual, sanitização de HTML, rastreamento dinâmico de manchas para DOM XSS, fuzzing diferencial de análise, Content Security Policy (CSP) e controles da cadeia de suprimentos. Além disso, propomos um projeto para um "Verificação de XSS" com um clique O Penligent é um recurso de análise de dados que inclui pipelines automatizados, modelos de varredura reutilizáveis, instrumentação em tempo de execução e geração de relatórios. Este documento é adequado para inclusão direta em whitepapers de engenharia ou documentação de produtos.

Motivação

As vulnerabilidades XSS permitem que os invasores injetem scripts executáveis em páginas da Web que, de outra forma, seriam benignas, executando-as efetivamente no navegador da vítima sob os privilégios de domínio do site. Esses ataques podem exfiltrar dados confidenciais (cookies, localStorage), executar ações não autorizadas ou desfigurar o conteúdo. (Documentos da Web da MDN)

Apesar de décadas de conscientização e técnicas de atenuação, o XSS continua sendo um risco persistente. O aumento da renderização no lado do cliente, as estruturas dinâmicas de JavaScript, os scripts de terceiros e os sistemas de modelos cada vez mais complexos tornaram mais difícil garantir a correção.

Objetivos deste guia:

• Combine as regras práticas do OWASP Cheat Sheet com pesquisas acadêmicas e de engenharia atualizadas.
• Ofereça uma arquitetura de defesa robusta e em várias camadas, em vez de uma única bala de prata.
• Apresentar um projeto concreto para que a Penligent forneça um Verificação de XSS com um clique recurso, unindo pesquisa e produto.

Fundamentos: Codificação contextual e pias seguras

Um princípio fundamental da prevenção de XSS é: nunca permitir que dados brutos não confiáveis cheguem a um contexto executável sem codificação ou sanitização adequada. A codificação deve ser adequada ao contexto (corpo HTML, atributo, literal JavaScript, CSS ou URL). Essa é a essência da Folha de dicas de prevenção de XSS da OWASP. (cheatsheetseries.owasp.org)

Regras de codificação de saída contextual

Na prática, prefira sempre as bibliotecas de codificação incorporadas ou bem testadas. Evite fazer suas próprias substituições ad hoc.

Pias seguras e como evitar APIs perigosas

Mesmo com a codificação correta, determinadas APIs são inerentemente arriscadas. Exemplos de sumidouros perigosos incluem:

• innerHTML, outerHTML
• document.write, document.writeln
• eval(), Função() construtor
• Manipuladores de eventos em linha (por exemplo onclick="..." com conteúdo dinâmico)

Prefira alternativas seguras:

• .textContent ou .innerText para inserir texto
• elemento.setAttribute() (para nomes de atributos controlados)
• Métodos DOM (por exemplo appendChild, createElement) sem concatenação de strings

Sanitização de HTML quando o HTML avançado é necessário

Em cenários em que o conteúdo fornecido pelo usuário pode incluir algum HTML (por exemplo, editores WYSIWYG, comentários com marcação limitada), a sanitização é necessária. A abordagem principal é:

1. Lista de permissões tags, atributos e padrões de valores de atributos permitidos.
2. Use bibliotecas maduras (por exemplo, DOMPurify) em vez de regexes personalizadas frágeis.
3. Esteja ciente de ataques diferenciais de análiseSe o navegador não tiver um analisador de HTML, o comportamento de análise do sanitizador pode ser diferente do analisador de HTML do navegador, o que leva a desvios.

Uma linha de pesquisa conhecida demonstra como os higienizadores e os navegadores podem divergir na interpretação da marcação de letras maiúsculas e minúsculas, permitindo escapes por meio de tokenização alternativa. (Consulte a pesquisa "Parsing Differentials")

Detecção de XSS com base em DOM por meio do rastreamento de contaminação em tempo de execução

As técnicas do lado do servidor não podem capturar de forma confiável DOM XSS (injeção no lado do cliente), porque o coletor relevante pode estar no JavaScript após o carregamento da página. O rastreamento dinâmico de contaminação (marcação de fontes não confiáveis e observação da propagação) é um método bem estudado.

• TT-XSS (por R. Wang et al.) é uma implementação clássica da detecção de XSS DOM baseada em contaminação dinâmica. (科学直通车)
• Falando sobre minha geração usa análise dinâmica de fluxo de dados para gerar explorações DOM XSS direcionadas. (ResearchGate)
• TrustyMon (2025) demonstra um sistema prático de monitoramento de tempo de execução que pode detectar XSS baseado em DOM em aplicativos do mundo real com alta precisão e baixos falsos positivos. (Biblioteca digital da ACM)

Esses sistemas instrumentam a execução no lado do cliente, marcam entradas não confiáveis (por exemplo, hash de URL, parâmetros de consulta, elementos do DOM) e detectam quando elas atingem coletores perigosos (por exemplo innerHTML) de uma forma que resulte na execução do script.

Uma ressalva: o rastreamento do tempo de execução tem um custo de desempenho. Alguns trabalhos combinam ML/DNN como pré-filtro para reduzir a sobrecarga do rastreamento de manchas. Por exemplo, Melicher et al. propõem o uso da aprendizagem profunda para pré-classificar as funções provavelmente vulneráveis e aplicar o rastreamento de contaminação somente ali. (contrib.andrew.cmu.edu)

Exemplo A - Fixo (usar pia segura) textContent)

<html>
  <head><title>Bem-vindo</title></head>
  <body>
    <h1>Olá!</h1>
    <div id="greeting"></div>
    <script>
      function getQueryParam(name) {
        return new URLSearchParams(window.location.search).get(name);
      }
      var raw = getQueryParam("name") || "";
      // Use textContent to insert as plain text (safe)
      document.getElementById("greeting").textContent = raw;
    </script>
    <p>Bem-vindo ao nosso site.</p>
  </body>
</html>

Por que isso é seguro: textContent escreve texto simples; mesmo que bruto contém <script>…</script>ele será renderizado como texto e não executado. Também usando URLSearchParams evita a análise frágil de índice/substring. portswigger.net

Exemplo B - coletor de atributos e manuseio seguro de URL (pseudo coletor de href)

Padrão vulnerável:

// Vulnerável:
var params = new URLSearchParams(window.location.search);
var target = params.get("url"); // controlado pelo usuário
document.getElementById("mylink").href = target;

Se alvo é um código javascript, clicar no link executa o JS.

Padrão seguro (esquema de validação):

function safeHref(input) {
  try {
    var u = new URL(input, window.location.origin);
    if (u.protocol === "http:" || u.protocol === "https:") {
      return u.toString();
    }
  } catch(e) { /* invalid URL */ }
  return "#";
}
document.getElementById("mylink").href = safeHref(params.get("url"));

Explicação: novo URL() normaliza; permitimos apenas http:/https: esquemas. Isso bloqueia javascript:/dados: esquemas. portswigger.net

Política de segurança de conteúdo (CSP): Defesa em profundidade

Embora a codificação e a sanitização sejam as principais defesas, o CSP oferece uma barreira secundária forte. Um CSP bem configurado usando nonces ou hashes, juntamente com estritamente dinâmico e remoção de 'inseguro em linha'pode restringir bastante a exploração de XSS.

No entanto, existem armadilhas:

• Reutilização de nonce: Alguns sites reutilizam o mesmo nonce em várias respostas, o que prejudica as proteções do CSP. Um estudo recente "The Nonce-nce of Web Security" mostra que muitos sites do mundo real fazem isso. (arXiv)
• Complexidade da implementação: o suporte a scripts legados em linha, bibliotecas de terceiros e inconsistências de navegadores geralmente leva à flexibilização das políticas.

Portanto, o CSP deve complementar, e não substituir, a codificação e a sanitização.

Práticas recomendadas de engenharia: CI, Lint, Testes, Monitoramento

Para operacionalizar defesas robustas contra XSS:

• ESLint / Revisores de códigoProibir ou sinalizar o uso de sumidouros não permitidos (innerHTML, eval), exigir anotações de contexto em expressões de modelo.
• Análise estática e dinâmica em CI:
  • Análise estática de contaminação em vários arquivos para módulos JS
  • Testes de fuzz ou testes de análise diferencial
  • Instrumentação de tempo de execução em ambientes de preparação
• Testes de unidade/segurançaGerar cargas úteis baseadas em contexto em testes de unidade para garantir que a codificação correta seja aplicada (como em "Detecção e reparo automatizados de vulnerabilidades de XSS" ou "Detecção de XSS por meio de testes de unidade") (arXiv)
• Monitoramento e alertasColeta de relatórios de violação de CSP, alertas de tempo de execução instrumentados para fluxos suspeitos, métricas de registro de falhas de codificação.

Projeto de varredura de XSS com um clique da Penligent

Abaixo está uma proposta de especificação de projeto que você pode incorporar ao produto da Penligent como um Varredura de XSS com um clique no "Playbook".

Fluxo de trabalho da tarefa (alto nível)

1. Rastreamento e renderização de JS - descobrir todas as páginas e rotas orientadas por JS.
2. Análise estática - propagação de contaminação no código-fonte para localizar funções e sumidouros de alto risco.
3. Digitalização de modelos - usar scanners com modelos (por exemplo, Nuclei) para disparar cargas úteis comuns de XSS.
4. Tempo de execução / verificação dinâmica - usando navegação sem cabeça e instrumentação, injetar cargas úteis e detectar a execução de scripts.
5. Rastreamento de manchas em tempo de execução - instrumentar o tempo de execução da página e observar se os dados não confiáveis chegam a coletores perigosos.
6. Teste de fuzz diferencial de análise - alimentar a marcação de casos extremos para o higienizador + navegador e detectar divergências.
7. Auditoria CSP e SRI - inspecionar cabeçalhos, tags de script, verificar a reutilização de nonce, atributos de integridade ausentes.
8. Geração de relatórios - Reúna vulnerabilidades com PoCs, classificação de risco, sugestões de correção e, opcionalmente, gere patches de PR.

Modelo de núcleos de amostra (XSS refletido)

id: xss-reflect-basic
info:
  name: XSS Refletido Básico
  autor: penligent-scan
  severidade: alta
solicitações:
  - method: GET
    path:
      - "{{BaseURL}}?q={{{payload}}"
    payloads:
      payload:
        - ""
    matchers:
      - tipo: palavra
        parte: corpo
        palavras:
          - ""

Você expandiria com conjuntos de carga útil com reconhecimento de contexto (atributo, JS, URL) e encadearia a verificação sem cabeça para reduzir os falsos positivos.

Exemplo de definição de tarefa (JSON)

{
  "name": "XSS QuickScan",
  "etapas": [
    {"id": "crawl", "type": "crawler", "params": {"start_url": "{{target}}", "render_js": true}},
    {"id": "static", "type": "static_analysis", "deps": ["crawl"], "params": {"analyzers": ["multi-file-taint"]}},
    {"id": "template_scan", "type": "scanner", "deps": ["crawl"], "params": {"templates": ["xss-reflect-basic"]}},
    {"id": "dynamic", "type": "dynamic_scan", "deps": ["template_scan", "static"], "params": {"engine": "headless-instrumented"}},
    {"id": "dom_taint", "type": "runtime_taint", "deps": ["dynamic"], "params": {"agent": "instrumented-browser"}},
    {"id": "parsing_diff", "type": "parsing_diff", "deps": ["dynamic"], "params": {}},
    {"id": "audit_csp", "type": "csp_audit", "deps": ["crawl"], "params": {}},
    {"id": "report", "type": "report_gen", "deps": ["dom_taint", "parsing_diff", "audit_csp"], "params": {"format": "pdf,html"}}
  ]
}

Relatório e resultado

Cada descoberta inclui:

• Tipo (refletido / armazenado / DOM)
• Prova de conceito (solicitação/resposta HTTP, instantâneo DOM, captura de tela)
• Pontuação de gravidade
• Sugestões de correção (por exemplo, codificador correto, configuração do higienizador, uso seguro da API)
• Opcionalmente, gerar automaticamente um patch ou esqueleto de PR

Você também pode criar um link para a literatura relevante (por exemplo, citando o TrustyMon, analisando documentos diferenciais) no relatório técnico interno.

Exemplos de snippets de código e práticas recomendadas

Aqui estão alguns trechos ilustrativos seguros/não seguros em uma configuração semelhante à do React:

Inseguro (vulnerável)

importar DOMPurify de 'dompurify';
function UserGreeting(props) {
  const clean = DOMPurify.sanitize(props.userContent, { ALLOWED_TAGS: ['b','i','u','a'], ALLOWED_ATTR: ['href'] });
  Retorno <div dangerouslysetinnerhtml="{{" __html: clean }} />;
}

function UserGreeting(props) {
  return <div>{props.userContent}</div>; // O React escapará automaticamente
}

// Unsafe
<img src={userInput} />

// Safer
function safeUrl(u) {
  const doc = new URL(u, window.location.origin);
  if (doc.protocol === 'http:' || doc.protocol === 'https:') {
    return doc.toString();
  }
  return '/';  // fallback
}
<img src={safeUrl(userInput)} />