O XSS baseado em DOM ocorre quando scripts maliciosos são executados por meio de JavaScript client-side que modifica o DOM de forma insegura. Ao contrário do XSS tradicional, esses ataques não precisam interagir com o servidor. Costumam explorar JavaScript vulnerável que processa dados vindos de fontes inseguras, como parâmetros de URL. A prevenção exige um tratamento cuidadoso da entrada do usuário no código client-side e a codificação adequada das saídas.
O cross-site scripting baseado em DOM é uma falha do lado do cliente em que a vulnerabilidade reside inteiramente no JavaScript da página, e não na resposta do servidor. A página lê dados de uma fonte que o invasor pode influenciar, comumente o fragmento da URL (location.hash), a query string, o document.referrer ou o armazenamento web, e os passa para um sink perigoso como innerHTML, o método document write ou eval sem sanitizá-los. O navegador então interpreta os dados do invasor como marcação ou código e os executa. Como o valor contaminado pode nunca deixar o navegador, o payload pode ficar depois do hash em uma URL, que os servidores não recebem, então o servidor nunca vê o ataque e não consegue registrá-lo nem filtrá-lo.
O XSS de DOM concede os mesmos poderes dentro da origem que os outros tipos de XSS: ler tokens e dados da página, forjar requisições e reescrever a interface, tudo sob a origem confiável do site. Ele é fácil de passar despercebido porque as defesas do lado do servidor, os web application firewalls e o registro de requisições não se aplicam a dados que ficam no navegador ou se escondem no fragmento da URL. As single-page applications modernas ficam especialmente expostas, já que roteamento, templating e renderização acontecem todos no lado do cliente e dependem fortemente de valores da URL e do armazenamento. À medida que os frameworks empurram mais lógica para o navegador, os sinks baseados em DOM se multiplicam, e uma única atribuição insegura a innerHTML em um componente muito usado pode expor todas as páginas que o renderizam.
Previna o XSS de DOM mantendo dados não confiáveis fora dos sinks perigosos: prefira textContent a innerHTML, evite eval e métodos legados de escrita no documento, e roteie qualquer HTML que precise inserir por um sanitizador confiável ou pela Sanitizer API e Trusted Types do navegador. O data binding dos frameworks e uma Content Security Policy reduzem a superfície restante. A cside não reescreve a lógica de DOM da sua aplicação, mas observa o que é executado no navegador em tempo de execução. Seu método Script analisa os payloads dos scripts de terceiros, consegue bloquear comportamentos maliciosos e registra o que de fato rodou, de modo que um script injetado ou comprometido que tente exfiltrar dados é pego pelo comportamento, e não pela origem, e essa evidência atende à PCI DSS 6.4.3 e 11.6.1.
No XSS refletido o servidor injeta o payload no HTML que devolve. No XSS baseado em DOM a resposta do servidor está limpa, e a falha está no JavaScript do lado do cliente, que lê um valor controlado pelo invasor e o escreve em um sink perigoso. O exploit pode residir no fragmento da URL, que o servidor nunca recebe.
Porque o payload muitas vezes nunca chega ao servidor. Valores colocados depois do hash em uma URL ficam no navegador, e outras fontes como o local storage ou o referrer são processadas puramente no lado do cliente. Um firewall só inspeciona o tráfego que vê, então fica cego a ataques executados inteiramente dentro do DOM.
We answer client-side security questions every day. Bring yours.