Resumo: JavaScript ofuscado e evasão de CSP
- Passa por declaração: JavaScript ofuscado passa CSP declarando apenas o que o CSP permite. O comportamento malicioso começa depois que o script carrega.
- Domínios, não integridade: CSP permite domínios, não integridade de código. Um domínio confiável comprometido ainda passa. Polyfill.io passou pelo CSP em 490.000 sites.
- Conformidade exige mais: 6.4.3 e 11.6.1 exigem detecção além de CSP: inventário de scripts, verificação de integridade, detecção de adulteração.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
Três rotas que o código ofuscado usa para contornar a CSP
A CSP controla fontes, não payloads. Três padrões de ataque exploram esta lacuna:
Compromisso de CDN de confiança ou host de terceiros. O script carrega de um domínio já presente na lista de permissões. Um payload modificado não aciona a CSP porque o URL de fonte não se altera. O Polyfill[.]io, os ataques de web skimming Magecart e recentes compromissos de CDNs de análise seguem esta rota.
Injeção em ficheiros próprios. Um atacante com acesso ao servidor injeta código ofuscado num ficheiro JavaScript próprio existente. Esse ficheiro carrega do domínio do site, que é sempre permitido.
Construção dinâmica de código em tempo de execução. Um script aprovado carrega e monta uma função maliciosa a partir de fragmentos de strings em tempo de execução, usando eval(), Function() ou equivalentes indiretos. O payload perigoso nunca existe em qualquer recurso carregado; é construído dentro do navegador após um carregamento de página limpo.
Nenhuma destas rotas viola uma lista de permissões de fontes. A CSP reporta limpo enquanto o malware ofuscado é executado.
Como os scripts ofuscados também evitam os scanners automáticos
A ofuscação remove os sinais legíveis que tanto os revisores humanos como os scanners automáticos procuram:
| Técnica | O que faz | Por que os scanners a perdem |
|---|---|---|
| Divisão e concatenação de strings | Divide URLs e palavras-chave em fragmentos unidos em tempo de execução | Nenhuma string completa aparece na fonte estática |
| Codificação Base64 com descodificação dinâmica | Armazena o payload como um blob descodificado apenas na execução | Parece dados, não código executável, para um analisador estático |
| Sequências de escape hexadecimal ou Unicode | Codifica caracteres como \x61 ou A | As ferramentas estáticas precisam executar o código para resolver o valor real |
| Nomes de variáveis aleatórios | Substitui identificadores legíveis por nomes curtos aleatórios | Remove o sinal de palavras-chave em que os detetores de padrões confiam |
| Carregamento dinâmico tardio | Obtém o payload real de um servidor C2 após a execução de um script aprovado | O recurso carregado difere em cada análise |
Os hashes de Subresource Integrity (SRI) defendem contra substituições silenciosas de payloads de fontes conhecidas, mas apenas quando um hash pode ser fixado para cada ficheiro. Scripts de terceiros que se atualizam frequentemente tornam o SRI impraticável em produção, o que constitui o desafio central na gestão de integridade de scripts dinâmicos. O SRI também não consegue proteger contra payloads obtidos dinamicamente de um endpoint C2, porque esse payload não estava presente quando qualquer hash foi calculado.
Porque os scanners estáticos não veem um CDN sequestrado
As ferramentas de análise estática e de composição de software leem o código antes de este correr. Encontram pacotes com CVE publicados, padrões inseguros como atribuições a innerHTML a partir de entrada do utilizador, e dependências desatualizadas. O que não conseguem fazer é observar o que um CDN entrega realmente ao navegador de um visitante.
O incidente do polyfill[.]io é o exemplo mais claro. Quando a Funnull adquiriu o domínio em fevereiro de 2024, o código-fonte de cada site que incorporava o script manteve-se inalterado. O CDN começou a injetar JavaScript malicioso nas respostas que servia, mas apenas para utilizadores móveis, apenas com um referrer falsificado, e apenas quando o visitante não tinha um padrão de cookies associado ao Google Analytics e às ferramentas de programação.
Um scanner estático teria visto <script src="https://cdn.polyfill[.]io/v3/polyfill.min.js"> no HTML e não teria encontrado qualquer CVE. Também não havia um hash estável para fixar: o endpoint gerava uma resposta por pedido, precisamente o caso em que a SRI não se aplica. O ataque era invisível para qualquer ferramenta que analise código em repouso. Quando os investigadores identificaram o payload em junho de 2024, cerca de 490.000 sites já o serviam a utilizadores reais.
A entrega condicional é o que torna esta classe difícil de apanhar a partir de fora da sessão. Os atacantes condicionam os payloads ao user agent, ao referrer, à geografia e à hora do dia precisamente para ficarem fora da monitorização sintética e dos perfis de navegador dos investigadores. Um payload que só dispara para utilizadores móveis de um país numa tarde específica nunca aparece numa análise estática nem se reproduz num crawler.
Abordagens para proteção contra JavaScript ofuscado
| Abordagem | Controlo de fontes | Inspeção de payload | Trata compromisso de host de confiança | Deteta injeção dinâmica em tempo de execução |
|---|---|---|---|---|
| CSP | Sim | Não | Não | Não |
| Subresource Integrity (SRI) | Parcial | Apenas hash | Parcial | Não |
| WAF ou filtragem de camada de rede | Parcial | Não | Não | Não |
| Análise estática de JavaScript | Não | Parcial | Parcial | Não |
| Monitorização comportamental na camada do navegador | Opcional por política | Sim | Sim | Sim |
A monitorização na camada do navegador é o único controlo nesta tabela que sobrevive às três rotas de evasão descritas. Funciona em conjunto com a CSP e cobre a lacuna de visibilidade de payload que a CSP deixa em aberto.
O que exigir de uma ferramenta resistente à evasão de CSP
Quatro perguntas antes de incluir um fornecedor na lista restrita:
Observação de payload em tempo de execução. A ferramenta analisa o que os scripts executam dentro do navegador, não apenas os URLs a partir dos quais carregam? Peça ao fornecedor para demonstrar a deteção de um script que carrega de um domínio de confiança e chama um endpoint de exfiltração não autorizado. Se a demonstração precisar de um URL de fonte maliciosa para ativar, a ferramenta depende da fonte.
Deteção de padrões de código ofuscado. Faça perguntas específicas sobre divisão de strings, equivalentes de eval() e descodificação dinâmica de Base64. Ferramentas que apenas sinalizam eval() literalmente perderão a maior parte da ofuscação real.
Monitorização comportamental pós-carregamento. Muitos ataques obtêm o seu payload real de um servidor C2 após o carregamento inicial da página. A ferramenta deve continuar a monitorizar além de DOMContentLoaded, não apenas na análise inicial.
Explicabilidade dos alertas. Um alerta que apenas diz "script suspeito detetado" não é acionável. Cada descoberta deve identificar o script, o comportamento que acionou a deteção e a chamada de rede tentada, para que um analista possa triar sem adivinhar.
Como o cside se encaixa neste cenário
O cside instrumenta o navegador através de um script que é executado dentro de cada sessão de visitante. Observa o que cada script de terceiros e próprio faz em tempo de execução: chamadas de rede efetuadas, alterações DOM aplicadas, campos de dados sensíveis acedidos e padrões de execução ofuscados detetados.
Quando um CDN comprometido serve um payload ofuscado a uma página instrumentada pelo cside, a deteção aciona no que o payload faz em tempo de execução (chamada de rede não autorizada, cadeia eval ofuscada, padrão de exfiltração de dados) em vez de na sua origem. Uma falha na lista de permissões de fontes não pode produzir um falso negativo num sistema baseado em comportamento.
Os requisitos 6.4.3 e 11.6.1 do PCI DSS v4.0.1 (obrigatórios desde março de 2025) exigem que os comerciantes autorizem todos os scripts nas páginas de pagamento e detetem modificações não autorizadas no conteúdo dos scripts ou nos cabeçalhos HTTP. A monitorização comportamental na camada do navegador fornece a evidência ao nível da execução que esses controlos esperam de uma camada de monitorização que alcança o interior do navegador, em vez de parar no perímetro da rede.
Para mais informações sobre as limitações práticas da CSP, consulte por que a CSP não funciona. Para uma análise técnica dos métodos de ofuscação usados em ataques reais, consulte o guia de desofuscação de JavaScript de terceiros.
