A injeção de JavaScript ocorre quando um atacante consegue inserir e executar código JavaScript não autorizado em uma aplicação web. Isso pode levar a roubo de dados, sequestro de sessão ou outras ações maliciosas. A prevenção exige validação adequada das entradas, codificação das saídas, a implementação de uma Content Security Policy e um tratamento cuidadoso da avaliação de código dinâmico.
A injeção de JavaScript é a inserção e execução de JavaScript não autorizado dentro de uma aplicação web. Ela chega ao navegador por vários caminhos: falhas de cross-site scripting que devolvem entrada sem escape em uma página, avaliação dinâmica insegura de strings via eval, o construtor Function ou callbacks de timer, scripts de terceiros comprometidos ou maliciosos carregados de um CDN, e dados controlados pelo invasor escritos em um contexto de script. Assim que o código roda, o navegador o trata como script legítimo pertencente à origem do site. Algumas definições também incluem o self-XSS de console do navegador e bookmarklets, em que o usuário é enganado a colar código do invasor. Em todos os casos, a característica definidora é que um JavaScript que o desenvolvedor nunca pretendeu acaba executando dentro da página.
O JavaScript injetado roda com toda a autoridade da origem da página, então seu alcance é amplo. Ele pode ler e exfiltrar cookies, tokens de sessão e conteúdo do DOM, sequestrar sessões, registrar teclas digitadas e campos de formulário, enviar requisições silenciosamente, reescrever a interface e carregar mais payloads. Em páginas de checkout, esse é o mecanismo por trás dos skimmers digitais e do Magecart: algumas linhas adicionadas a um script confiável copiam discretamente os campos de cartão e endereço para o domínio do invasor, enquanto os logs do servidor e os firewalls não veem nada, porque o roubo acontece inteiramente no navegador. Os invasores costumam ofuscar o código e restringi-lo a páginas ou condições específicas para escapar da revisão, deixando um único script injetado rodar sem ser detectado em muitos usuários por meses.
Reduza a superfície eliminando a avaliação dinâmica de código, codificando a saída, validando a entrada e aplicando uma Content Security Policy estrita com nonces ou Subresource Integrity, para que apenas scripts verificados rodem. Mas uma CSP confia nos scripts pelo domínio de origem, então um fornecedor da allowlist comprometido ainda executa. É aqui que a cside se encaixa diretamente: ela roteia os scripts de terceiros por um método Script e analisa o payload JavaScript real antes que ele rode, pegando comportamentos maliciosos, como ler campos de cartão ou contatar um domínio desconhecido, pelo que o código faz, e não por onde ele é carregado. A cside consegue bloquear esse comportamento em tempo real e mantém um registro forense do código exato que rodou, que é o que a PCI DSS 6.4.3 e 11.6.1 exigem.
O XSS é a forma mais comum de a injeção de JavaScript acontecer, injetando script por meio de entrada sem escape. Mas a injeção também pode ocorrer sem uma falha clássica de XSS: por um script de terceiros comprometido, pela avaliação insegura de dados dinâmicos, ou por um usuário enganado colando código no console. O XSS é um caminho para a injeção de JavaScript, não o único.
Uma CSP restringe quais domínios e scripts inline podem rodar, o que bloqueia muitas injeções, mas ela confia em qualquer script servido de uma origem na allowlist. Se um fornecedor que você já permite for comprometido, o código injetado executa como legítimo. Impedir isso exige inspecionar o que cada script de fato faz, não apenas de onde ele vem.
We answer client-side security questions every day. Bring yours.