A proteção resistente à evasão de CSP refere-se a controlos de segurança que detetam e bloqueiam JavaScript malicioso mesmo quando esse código usa ofuscação, carregamento dinâmico ou injeção via hosts de confiança para contornar a Content Security Policy. A CSP impõe uma lista de permissões de fontes de scripts aprovadas, mas não consegue inspecionar o que essas fontes aprovadas executam. Os controlos resistentes à evasão observam o comportamento em tempo de execução de cada script dentro da sessão do navegador, detetando ameaças que passam pelas verificações de lista de permissões sem acionar uma única violação de política.
O ataque à cadeia de fornecimento do Polyfill[.]io em junho de 2024 mostrou esta lacuna. Mais de 490.000 sites tinham cdn.polyfill[.]io na sua lista de permissões CSP. Quando o domínio mudou de proprietário e o novo operador substituiu a biblioteca legítima por malware ofuscado, cada site afetado carregou e executou o payload malicioso enquanto a CSP não reportava qualquer violação. (Investigação Sansec, junho de 2024)
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.
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.
