A ofuscação de JavaScript é o processo de tornar o código mais difícil de entender sem perder sua funcionalidade. Embora existam usos legítimos, como a proteção de propriedade intelectual, atores maliciosos costumam usar a ofuscação para esconder código de ataque. As ferramentas de segurança modernas precisam equilibrar a detecção de código ofuscado malicioso com o respeito às necessidades legítimas de negócio de proteger o código.
A ofuscação de JavaScript transforma código-fonte legível em uma forma funcionalmente idêntica, mas difícil de ler. Técnicas comuns incluem renomear variáveis e funções para caracteres sem sentido, codificar strings como hex ou base64 e decodificá-las em tempo de execução, empacotar o código em grandes arrays indexados por deslocamentos numéricos, envolver a lógica em eval ou no construtor Function, inserir código morto e achatar o fluxo de controle, substituindo ramificações comuns por um laço despachante. A saída ainda é interpretada e executada da mesma maneira no navegador, mas uma pessoa que a lê não consegue perceber facilmente o que ela faz. Ferramentas como o javascript-obfuscator automatizam essas passagens, e os minificadores aplicam uma versão mais leve da mesma ideia para reduzir o tamanho do arquivo.
A ofuscação tem uso duplo. Fornecedores a utilizam para proteger propriedade intelectual ou dificultar a engenharia reversa, mas os atacantes dependem dela para esconder skimmers, redirecionadores e código de exploração dentro de scripts que, de outra forma, seriam confiáveis. Strings codificadas ocultam domínios de exfiltração e seletores de campos de cartão, enquanto a decodificação em tempo de execução derrota a varredura estática por palavras-chave e muitas heurísticas de Content Security Policy. Como um scanner baseado em assinaturas não consegue casar com strings que só existem depois que o código se decodifica, malwares fortemente ofuscados frequentemente sobrevivem à revisão automatizada e às listas de bloqueio. Isso também aumenta o custo da resposta a incidentes: após uma violação, os investigadores precisam desofuscar manualmente o payload para descobrir quais dados foram roubados e para onde foram enviados.
Você não pode simplesmente banir a ofuscação, porque bundles minificados legítimos parecem semelhantes. A abordagem confiável é julgar os scripts pelo comportamento em vez da legibilidade: analise ou execute o código e observe o que ele realmente faz, se lê campos de formulário, contata domínios desconhecidos, reescreve o DOM, em vez de tentar casar padrões no código-fonte. A cside encaminha scripts de terceiros por um método Script e analisa o payload real de JavaScript, de modo que um skimmer ofuscado é detectado pelo comportamento que ele exibe em tempo de execução, e não pelo fato de seu código-fonte ser ou não legível por humanos. A cside pode bloquear esse comportamento em tempo real e mantém um registro forense do código exato que foi executado, o que dá suporte ao PCI DSS 6.4.3 e 11.6.1.
Não. Minificadores e ferramentas comerciais de proteção de código ofuscam scripts legítimos para reduzir o tamanho ou desencorajar cópias, então a ofuscação por si só não é prova de um ataque. O sinal de segurança é o que o código faz em tempo de execução, não o quão ilegível ele parece. Julgar os scripts pelo comportamento evita bloquear bundles benignos de fornecedores.
Uma CSP controla quais origens podem carregar ou executar scripts; ela não inspeciona o que um script permitido contém. Se um fornecedor da lista de permissões distribuir um skimmer ofuscado, a CSP ainda o executa. A ofuscação também pode esconder padrões de eval inline, então é preciso análise no nível do payload junto com a CSP.
We answer client-side security questions every day. Bring yours.