Ofuscacao de JavaScript e o processo de tornar o codigo mais dificil de entender mantendo sua funcionalidade. Embora usos legitimos incluam protecao de propriedade intelectual, atores maliciosos frequentemente usam ofuscacao para esconder codigo de ataque. Ferramentas de seguranca modernas devem equilibrar a deteccao de codigo ofuscado malicioso respeitando necessidades comerciais legitimas de protecao de codigo.
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 proxy híbrido 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.