O crescimento acelerado das injeções DOM: por que as soluções antifraude tradicionais estão falhando

A maioria dos sistemas antifraude e de segurança hoje analisa apenas a transação finalizada: os sinais que ela carrega e o quanto o comportamento do usuário se aproxima dos padrões estabelecidos. Durante anos, os ataques de cross-site scripting (XSS) foram considerados relativamente fáceis de detectar e controlar. O código malicioso era injetado por meio de parâmetros da requisição, executado no navegador e deixava rastros evidentes — na URL, nos logs do servidor e no comportamento da página. Cenários clássicos, como stored XSS e reflected XSS, normalmente podiam ser identificados e bloqueados na camada da aplicação, via web application firewalls (WAFs) ou por meio da lógica server-side.

Hoje, a própria estrutura desses ataques mudou. A ameaça evoluiu para DOM-based XSS, e o ponto inicial da invasão foi transferido diretamente para o navegador. Em vez de uma injeção explícita, os atacantes agora interferem na página após o carregamento — manipulando o DOM (Document Object Model), que controla a estrutura da interface, os elementos dinâmicos e o comportamento das aplicações web.

À medida que as arquiteturas de front-end se tornam mais complexas, a dependência de scripts de terceiros aumenta e ferramentas especializadas de manipulação de navegador se popularizam, as transações passam a ser cada vez mais formadas dentro de um ambiente client-side já comprometido. O servidor recebe o que parece ser uma requisição totalmente legítima, e os sistemas de monitoramento enxergam sinais “normais” — mesmo quando o usuário, na prática, está interagindo com uma página ou funcionalidade modificada.

Neste artigo, explicamos:

• Como o XSS evoluiu para injeções DOM e client-side hijacking (também conhecido como ataques Man-in-the-Browser ou MITB);
• Como e em que escala esse problema se manifesta em diferentes regiões do mundo;
• Por que abordagens clássicas de antifraude e segurança são cegas para esses cenários;
• Quais estratégias de defesa realmente funcionam.

A análise tradicional de transações ignora completamente a etapa em que a transação é formada — e é justamente aí que uma parcela crescente dos ataques ocorre hoje.

O que é client-side hijacking (ataque MITB)?

Os ataques modernos acontecem cada vez menos por meio de alterações visíveis na barra de endereço e cada vez mais de forma silenciosa dentro do navegador do usuário — sem recarregar a página, modificar URLs ou deixar rastros evidentes no servidor. O usuário opera em um ambiente client-side alterado, enquanto o servidor e muitos sistemas antifraude continuam enxergando o que parece ser uma sessão legítima.

Essa é a principal mudança: a ameaça saiu das anomalias detectáveis no servidor e migrou para a manipulação discreta da lógica da interface e do comportamento do usuário diretamente no navegador. Nesse contexto, “hijacking” significa assumir o controle de forma invisível no lado do cliente.

Como o XSS migrou para o navegador: das vulnerabilidades server-side aos ataques DOM

O XSS clássico era relativamente simples. O código malicioso entrava por um parâmetro de URL — por exemplo, ?search=<script>...</script> — era executado imediatamente no navegador e deixava sinais visíveis.

As injeções DOM funcionam de outra forma. Em vez de ataques barulhentos baseados em URL, os invasores modificam elementos críticos da página após o carregamento. Por exemplo, podem alterar document.querySelector('.payment-form').action para que o formulário de pagamento continue aparentando funcionar normalmente, enquanto todos os dados são silenciosamente enviados para um destino controlado pelo atacante ou manipulados com ruído que afeta o risk scoring.

Essa substituição pode ocorrer por meio de extensões maliciosas de navegador, scripts de terceiros comprometidos, pacotes NPM contaminados, navegadores especializados ou infectados, malware no dispositivo ou qualquer código que consiga acesso ao DOM.

Do ponto de vista do servidor, o problema é que ele frequentemente recebe uma requisição completamente normal. Os sistemas backend registram atividade padrão do usuário. Até mesmo os WAFs não identificam URLs suspeitas, assinaturas de ataque ou erros. Nessa nova realidade, as ferramentas antifraude tradicionais orientadas ao server-side ficam praticamente cegas para o próprio fato da interferência.

As APIs de navegador mais perigosas nas mãos dos atacantes

Os atacantes não precisam inventar novas ferramentas. Eles simplesmente reutilizam APIs padrão do navegador — as mesmas usadas em operações legítimas da interface — transformando-as em mecanismos de interceptação e substituição.

O principal alvo são os eventos. O cenário mais óbvio é a interceptação do evento submit. Nesse momento, o usuário já preencheu o formulário, os dados estão prontos para envio e, do ponto de vista da lógica da aplicação, tudo parece concluído. É aí que o código malicioso ganha controle máximo: ele pode copiar os dados inseridos, modificá-los ou assumir totalmente o controle do envio, redirecionando-o para outro destino.

O usuário não percebe nada incomum — recebe a tela padrão de confirmação (“Pagamento realizado com sucesso”). Porém, o evento submit é apenas parte do problema. Na prática, os atacantes podem obter acesso a cadeias inteiras de ações do usuário ou a sinais suficientes para comprometer o usuário ou a conta.

O código malicioso moderno raramente se limita a uma única ação. Paralelamente ao ataque principal — como alterar form.action ou interceptar dados — ele gera atividade em segundo plano: criação e remoção de nós DOM, anexação de handlers adicionais, envio de requisições de rede aparentemente inofensivas, disparo de reflows desnecessários na interface ou sobrescrita de APIs essenciais do navegador e do WebView. Tudo isso se mistura naturalmente ao fluxo normal de eventos client-side, tornando extremamente difícil para sistemas de logging e monitoramento diferenciar a anomalia do ruído legítimo do front-end.

Dinâmica de crescimento das injeções client-side

Nos últimos três meses, observamos diferenças significativas nos níveis de injeções client-side entre regiões. Em alguns mercados, isso já se tornou um problema sistêmico, com alta penetração de ataques; em outros, ainda são casos isolados.

Atuando em um grande número de países, identificamos uma tendência clara: quanto mais empresas e reguladores investem em medidas de proteção, biometria, sistemas de “cool-down” contra engenharia social e outras camadas defensivas, maior é o crescimento das injeções DOM perigosas. Isso indica que, à medida que as defesas tradicionais se fortalecem, os atacantes migram cada vez mais para vetores client-side.

Abaixo, apresentamos uma análise por regiões-chave, mostrando onde o risco atualmente é mais elevado e onde ele começa a acelerar.

Táticas dessas ameaças de alto risco

O código malicioso moderno raramente depende de uma única ação. Além de manipulações centrais, como alterar form.action ou interceptar dados, ele gera atividade em segundo plano: criação e remoção de nós DOM, anexação de handlers extras, envio de requisições de rede aparentemente inocentes, disparo de reflows desnecessários ou sobrescrita de APIs básicas. Esse “ruído” se dissolve no fluxo de eventos legítimos do cliente, dificultando a identificação de anomalias em logs ou sistemas de monitoramento.

Um exemplo de alto risco: Web3 e carteiras cripto

Uma categoria particularmente perigosa envolve interfaces de carteiras cripto. Nesse cenário, o código malicioso substitui o endereço do destinatário, o QR code ou elementos de confirmação. Os usuários normalmente confiam na interface familiar e raramente verificam cada detalhe. Trata-se de um ataque à interface confiável: visualmente, nada muda, mas os dados críticos já foram alterados. Dada a natureza irreversível das transações em blockchain, as consequências são definitivas.

Esse risco está mais frequentemente associado a plugins maliciosos de navegador. Entre as principais APIs exploradas estão:

Storage API

localStorage, sessionStorage e IndexedDB: frequentemente utilizados para armazenar tokens, identificadores de sessão e parâmetros de serviço. O código malicioso pode ler esses valores para sequestrar a sessão ou modificá-los para alterar o comportamento da aplicação no momento certo. Uma vez obtido o token, o invasor pode continuar agindo em nome do usuário fora da sessão atual — sem reautenticação e sem sinais evidentes de comprometimento.

Canvas API

Em interfaces nas quais dados críticos são renderizados via canvas, os atacantes podem alterar informações exibidas, como números de cartão, valores ou endereços de carteira.

Navigator.sendBeacon

Uma API legítima usada para analytics e telemetria, o que a torna ideal para exfiltração silenciosa de dados. As informações podem ser enviadas no momento em que a aba é fechada, quando o usuário já não espera mais nenhuma atividade de rede. Essas requisições parecem eventos comuns de telemetria e raramente despertam suspeitas.

Por que os sistemas antifraude tradicionais são cegos

As soluções antifraude tradicionais fazem uma pergunta principal: “Este é um usuário real?”. As injeções DOM operam em um nível completamente diferente. O usuário pode ser totalmente legítimo, acessar a conta a partir de um dispositivo conhecido e seguir um padrão comportamental normal. O risco surge após o carregamento da página, quando a lógica da interface é silenciosamente alterada dentro do navegador. A sessão parece normal para o sistema antifraude — endereço IP, fingerprint do dispositivo e comportamento correspondem ao perfil do usuário. Enquanto isso, o envio do formulário é interceptado, os dados são substituídos e parte das informações é enviada para outro destino.

Por que recursos comportamentais baseados em machine learning não ajudam

Modelos antifraude comportamentais analisam características como tempo de preenchimento de formulários, movimentos do mouse, ritmo de digitação, pausas, taxas de erro e velocidade ao clicar em “Pagar”. Injeções DOM sofisticadas são projetadas justamente para imitar esses sinais com perfeição:

O preenchimento do formulário não ocorre instantaneamente. O código malicioso insere dados com pequenos atrasos aleatórios entre os caracteres (normalmente entre 80 e 120 ms), fazendo a atividade parecer humana.

Os movimentos do mouse são gerados com trajetórias naturais: curvas suaves, pausas e pequenas variações que ferramentas avançadas de automação hoje conseguem reproduzir de forma convincente.

Como resultado, o modelo comportamental classifica a atividade com confiança como proveniente de uma pessoa real.

Bureaus de crédito e biometria também não são suficientes

Um bureau de crédito pode identificar corretamente o cliente como de baixo risco — e estaria certo, porque o ataque não afeta o histórico de crédito. Ele acontece em tempo real dentro do navegador durante a sessão. Biométricas comportamentais e fisiológicas se concentram em movimentos do mouse, padrões de digitação, gestos, reconhecimento facial ou testes de vivacidade. Mas, se o ataque client-side opera dentro de uma sessão normal, preserva o padrão comportamental externo e mistura sinais sintéticos plausíveis, até mesmo a biometria deixará de perceber que a lógica da página foi manipulada. Os invasores simplesmente acompanham o usuário legítimo durante todas as verificações.

Soluções antivírus oferecem proteção limitada

Ferramentas antivírus tradicionais também não conseguem lidar plenamente com essa ameaça. Elas dependem de blacklists, verificações de integridade, assinaturas conhecidas de malware, arquivos suspeitos e URLs maliciosas. Injeções DOM perigosas frequentemente escapam dessas defesas — especialmente quando envolvem geração de ruído ou cenários em múltiplas etapas, nos quais cada ação individual parece inofensiva. A proteção precisa deixar de avaliar ações, procedimentos ou arquivos isolados e passar a analisar as consequências gerais ao longo de toda a sessão, incluindo comportamentos técnicos invisíveis para o usuário final (como o início e encerramento da sessão). Essa abordagem vai muito além daquilo para o qual soluções antivírus clássicas foram projetadas.

O que precisa ser analisado

Já não basta analisar apenas quem é o usuário, de onde ele veio, como movimentou o mouse ou a integridade básica do navegador e do sistema operacional. Também é necessário monitorar, em tempo real, a integridade do ambiente: o DOM foi alterado? O formulário ou o form.action foram modificados? Surgiram handlers de submit inesperados? Dados foram enviados via sendBeacon? Tokens foram lidos do storage em momentos suspeitos? Campos ocultos, overlays ou iframes apareceram repentinamente?

A análise precisa abranger não apenas o comportamento do usuário, mas também a integridade do ambiente em que esse comportamento acontece.

Estratégias eficazes de defesa: da análise estática ao monitoramento da integridade do DOM

A proteção server-side, sozinha, já não é suficiente — não porque seja ineficaz, mas porque ela não consegue enxergar o quadro completo. Como o ataque vive dentro do navegador, a defesa eficaz também precisa ter visibilidade sobre esse ambiente.

1. Subresource Integrity (SRI) informa ao navegador um hash criptográfico para arquivos JavaScript externos. Se o arquivo for alterado, ele não será carregado. O incidente do polyfill dot io em 2024 mostrou que ameaças podem surgir por meio de supply chains comprometidas, afetando simultaneamente milhares de sites sem que qualquer site individual tenha sido comprometido no sentido tradicional. O SRI funciona bem para recursos externos estáticos, mas não ajuda quando o próprio script autorizado executa lógica maliciosa ou é injetado dinamicamente pelo usuário (por exemplo, via extensões ou plugins de navegador).
2. Content Security Policy (CSP) com reporting restringe as origens de onde uma página pode carregar scripts. A diretiva report-uri permite coletar sinais de violação em produção — detectando tentativas de injeção inline ou carregamento de scripts a partir de domínios não autorizados antes que se transformem em incidentes completos.
3. O monitoramento do DOM é atualmente a abordagem mais avançada e eficaz. Um script client-side leve verifica continuamente a integridade de elementos críticos: estrutura de formulários, destinos de envio, aparecimento de campos ocultos, event handlers inesperados, iframes, overlays e violações de APIs essenciais. Quando um desvio é detectado, ele envia um sinal de risco ao sistema antifraude, aciona verificações adicionais ou encerra a sessão no nível do servidor. Diferentemente dos sistemas reativos — que detectam ataques apenas após sua ocorrência por meio de logs, eventos ou resultados de transações — essa abordagem identifica a ameaça em tempo real, enquanto ela ainda está se desenvolvendo.

O futuro da proteção — client-side Zero-Trust: JuicyScore e JuicyID

No passado, uma página carregada a partir de um domínio “correto” era considerada confiável por padrão. No universo das injeções DOM, essa lógica já não funciona. O princípio de client-side Zero-Trust significa que, mesmo dentro da sua própria página, não é possível confiar cegamente que o DOM, os event handlers, os scripts de terceiros e os detalhes exibidos permaneceram inalterados. Tanto a identidade do usuário quanto a integridade do ambiente client-side precisam ser verificadas.

Esse é exatamente o princípio por trás das soluções da JuicyScore. A JuicyScore analisa dados não pessoais para avaliar o risco da sessão e proteger usuários online contra fraudadores. A solução combina características comportamentais, dados de dispositivo e navegador e detecção de diversas anomalias — incluindo randomização, injeção de ruído e outras manipulações associadas a alto risco de fraude.

Além disso, a API v17 da JuicyScore introduziu novos atributos no vetor de resposta especificamente desenvolvidos para detectar injeções em diferentes níveis de risco — diretamente relacionados a essa ameaça. Estamos desenvolvendo ativamente essa direção e planejamos expandir ainda mais a classificação de riscos de injeções DOM em um futuro próximo.

O JuicyID é um produto mais especializado para proteção de contas. Ele identifica dispositivos e padrões comportamentais de risco, reduzindo o risco de account takeover sem impor verificações excessivas aos usuários legítimos. Sua tecnologia de autenticação de dispositivos, baseada no fingerprint digital estável JuicyDeviceID em combinação com outros atributos da JuicyScore, permite analisar o ambiente exato em que a sessão acontece — justamente a camada que permanece como ponto cego para sistemas tradicionais.

A fronteira que precisa ser protegida mudou. Ela já não está apenas no servidor ou no nível da identidade do usuário. Agora, ela passa pelo navegador, pela estrutura da página e por tudo o que acontece entre a inserção dos dados e o clique final no botão.

Uma estratégia antifraude que ignora a camada client-side opera com uma visão incompleta do risco. E esse ponto cego já está sendo explorado ativamente.

A era de depender exclusivamente da análise pós-transação está chegando ao fim. A proteção eficaz no cenário atual exige validação contínua e em tempo real do ambiente client-side onde as transações realmente nascem. Só assim as organizações conseguirão reduzir a lacuna crescente que as injeções DOM e o client-side hijacking continuam ampliando.