Cross-Site Scripting (XSS).

O Cross-Site Scripting (XSS) ocorre quando uma aplicação web reflete ou armazena entradas não confiáveis nas suas respostas sem escape sensível ao contexto, permitindo que JavaScript controlado pelo atacante seja executado no browser da vítima sob a origem do site — herdando os seus cookies, o acesso ao DOM e os privilégios de mesma origem (same-origin). As três classes são o refletido (payload devolvido a partir do pedido), o armazenado (payload persistido no servidor, p. ex. num comentário) e o baseado no DOM (o sink reside em JavaScript do lado do cliente, como innerHTML ou document.write).

A demonstração canônica do alcance do XSS armazenado é o worm Samy: em 4 de outubro de 2005, Samy Kamkar plantou um payload JavaScript no seu perfil do MySpace que o adicionava como amigo e se copiava para o perfil de cada visitante. Infectou mais de um milhão de contas em menos de 20 horas — o worm de propagação mais rápida da época — e levou a uma operação do Secret Service e a uma declaração de culpa por crime grave (felony). O XSS continua a ser um elemento básico do OWASP Top 10, integrado em A03:2021 (Injeção).

As defesas são em camadas: output encoding sensível ao contexto (HTML, atributo, JS, URL), uma Content-Security-Policy rigorosa com nonces ou hashes para bloquear scripts inline, auto-escaping do framework (React, Angular), Trusted Types para restringir sinks perigosos do DOM, e cookies HttpOnly/SameSite para limitar o roubo de sessão. A validação de entrada ajuda, mas não é suficiente por si só.

flowchart LR
  A[Atacante submete payload] --> W[Aplicação web armazena ou reflete a entrada]
  W -->|Saída sem escape| V[Browser da vítima renderiza a página]
  V --> X[Script do atacante executa na origem do site]
  X --> S[Roubar cookies/sessão, keylog, pivotar]