Os operadores de casinos online investem pesadamente na aquisição de jogadores através de afiliados, pesquisa paga e campanhas de influenciadores. Mas uma categoria crescente de ataques ao nível do browser está a desviar esses jogadores antes de chegarem ao lobby. No Q1 2025, o cside detectou mais de 300.000 sinais de ataque em sites monitorizados, muitos deles eventos de redirecionamento desencadeados por JavaScript injectado a correr silenciosamente dentro do browser. A superfície de ataque não é a sua infraestrutura de servidor. É o JavaScript a executar nos browsers dos seus jogadores após cada carregamento de página. Ao trabalhar com operadores de jogo multi-marca, vi este padrão de ataque aparecer repetidamente em ambientes onde a equipa de segurança não tinha ideia de que estava a ocorrer um redirecionamento, porque todas as ferramentas que tinham estavam a vigiar a camada errada.
Como Parecem os Ataques de Redirecionamento por Script Injectado
Resposta Rápida: Os redirects por script injectado funcionam inserindo um pequeno payload JavaScript numa recurso de terceiros confiável — como uma tag de afiliado, biblioteca de analytics, ou tag manager — que executa no browser do jogador após o carregamento da página. O script intercepta a jornada do jogador usando APIs nativas do browser e envia-o para um site concorrente ou destino fraudulento, completamente invisível para a monitorização server-side.
Os ataques de redirecionamento que utilizam JavaScript injectado não são teóricos. A divulgação do Sansec sobre o compromisso da cadeia de fornecimento do Polyfill.js em Junho de 2024 mostrou mais de 100.000 websites a servir código malicioso a partir de uma única biblioteca alojada em CDN que tinha sido vendida a um actor de ameaça. Para plataformas de jogo, a mecânica segue uma anatomia previsível.
O atacante ou compromete um script em que o seu site já confia ou encontra uma forma de injectar um novo script através de um vector aberto, como um tag manager. Uma vez que o seu payload está a executar no browser, tem acesso ao runtime JavaScript completo. A partir daí, tem várias técnicas de redirecionamento disponíveis.
As técnicas de redirect comuns utilizadas contra plataformas de jogo incluem:
- Chamadas
window.open()ouwindow.location.replace(): o jogador é enviado para um domínio diferente a meio da sessão - Substituição de listeners DOM: o script remove um handler de clique existente num botão CTA e substitui-o por um redirect para um concorrente ou destino de fraude de afiliado
- Manipulação de parâmetros URL: o script altera
return_url,redirect_uriou strings de query semelhantes que a plataforma utiliza para encaminhamento pós-login - Adulteração de
history.pushStateelocation.hash: redirects mais subtis que falsificam a barra URL sem desencadear um evento de navegação completo
Cada um destes executa inteiramente dentro do browser. Nenhum pedido HTTP é alterado antes de chegar aos seus servidores. Nenhum CDN vê o payload a ser entregue ao jogador.
Por Que Razão Estes Ataques Visam Especificamente Plataformas de Jogo
Resposta Rápida: As plataformas de jogo são desproporcionalmente visadas porque os seus funis de aquisição de jogadores são orientados por afiliados, as suas páginas de destino transportam muitos scripts de terceiros, e o valor monetizável de redirecionar mesmo uma pequena percentagem de jogadores que depositam é extremamente elevado. Um redirect que desvia 2% do tráfego durante uma campanha de bónus pode representar receita perdida significativa.
As plataformas de casino e de apostas desportivas têm características estruturais que as tornam atractivas para esta classe de atacante. Primeiro, o ecossistema de afiliados significa que dezenas de snippets de JavaScript externos são rotineiramente adicionados às páginas do operador (tracking pixels, scripts de postback, contadores de sub-afiliados), muitos deles adicionados por equipas de marketing sem revisão de segurança.
Segundo, a jornada do jogador que deposita tem momentos discretos de alto valor. Um redirect injectado apenas durante o fluxo de registo ou de depósito, com tempo para disparar depois de o jogador ter introduzido intenção de pagamento, pode desviar um utilizador de alto valor para uma marca concorrente ou para um site fraudulento que recolhe credenciais.
Terceiro, as capacidades de segmentação geográfica e de dispositivos do JavaScript moderno significam que os ataques podem ser cirurgicamente direccionados. Um payload malicioso pode verificar navigator.language, analisar geolocalização de IP via fetch em segundo plano, ou inspeccionar a string do user agent e apenas redirecionar utilizadores móveis em mercados regulados específicos. Esta precisão torna o ataque difícil de detectar através de QA manual porque não vai disparar no browser de computador do programador.
Estas condições combinam-se para criar uma ameaça que é operacionalmente invisível sob configurações de monitorização padrão.
Por Que Razão as Ferramentas de Camada de Rede Não Conseguem Ver Isto
Resposta Rápida: As ferramentas de camada de rede inspeccionam tráfego HTTP entre o servidor e o CDN ou balanceador de carga. Os ataques de redirect por JavaScript executam dentro do browser após a página ter sido completamente carregada. Nenhum pedido de rede é sinalizado porque o motor JavaScript do browser está a fazer o trabalho. Os logs de rede confirmam apenas que GTM.js ou analytics.js carregou com sucesso, não o que correu dentro deles.
O Cloudflare Page Shield, os WAFs e as soluções de monitorização de rede operam numa camada diferente da pilha. Podem dizer-lhe quais scripts foram pedidos. Podem bloquear domínios maliciosos conhecidos ao nível do DNS. O que não conseguem fazer é observar o runtime JavaScript a executar dentro do separador de browser de um utilizador.
Considere este cenário: um shadow GTM container é adicionado a um domínio de casino. O contentor carrega gtm.js, que é um URL legítimo do Google. Dentro desse contentor, uma tag dispara um bloco HTML personalizado que injecta um script de redirect apenas para utilizadores móveis na Alemanha que visitam através de uma fonte de tráfego de afiliado. A partir da camada de rede, os logs mostram que gtm.js carregou com código de estado 200. Nada é sinalizado.
Esta não é uma limitação específica de nenhum fornecedor. É uma fronteira arquitectural fundamental. O seu WAF protege o servidor. O cside protege o que corre nos browsers dos seus clientes. São camadas diferentes e são necessárias ferramentas diferentes para cada uma.
- As ferramentas de rede vêem: quais recursos foram pedidos, quais respostas HTTP foram devolvidas, e se essas respostas correspondem a assinaturas maliciosas conhecidas
- As ferramentas de rede não conseguem ver: que JavaScript executa após o carregamento da página, que mutações DOM acontecem em tempo real, ou para que valores
window.locationo browser envia um jogador
O único ponto de vista que pode observar estes eventos é uma camada de instrumentação a correr dentro do browser, ao lado do código que está a ser monitorizado.
Uma Análise Técnica: O Redirect via Shadow GTM
Resposta Rápida: Um ataque de redirect via shadow GTM carrega um ID de contentor com aparência legítima através de uma conta GTM pai autorizada, depois dispara uma tag HTML personalizada que usa window.open para abrir um site concorrente num novo separador durante o fluxo de depósito. Toda a cadeia é invisível para logs de servidor e WAFs porque cada pedido nela resolve para infraestrutura legítima do Google e da plataforma.
Eis como este ataque se desenrola passo a passo numa plataforma iGaming real.
Passo um: um actor de ameaça, seja um afiliado com acesso ao tag manager ou um contratante de marketing comprometido, adiciona um ID de GTM container secundário ao template global do site. O ID do contentor aparece ao lado do próprio contentor legítimo do operador. Para um programador a inspeccionar a página, ambos os contentores carregam www.googletagmanager.com/gtm.js, um domínio idêntico e confiável.
Passo dois: dentro do contentor malicioso, o atacante configurou uma tag HTML personalizada definida para disparar no gatilho "Todas as Páginas" ou, mais precisamente, num padrão de URL específico correspondendo à página de depósito. A tag contém:
(function() {
var ua = navigator.userAgent.toLowerCase();
var lang = navigator.language || navigator.userLanguage;
if (/mobile|android/.test(ua) && /de|at|ch/.test(lang)) {
window.addEventListener('DOMContentLoaded', function() {
document.querySelector('#deposit-btn').addEventListener('click', function(e) {
e.preventDefault();
window.open('https://competitor-offer.example.com/?ref=hijack123', '_blank');
}, true);
});
}
})();
Passo três: o jogador clica no botão de depósito. O listener de evento sequestrado dispara antes do legítimo (o argumento true define-o para a fase de captura, dando-lhe prioridade). O jogador é redirecionado. Os logs do operador mostram uma saída da página de depósito sem conversão.
Passo quatro: os analytics do operador mostram uma queda inexplicável na taxa de conversão móvel nas geos DACH. Sem instrumentação na camada do browser, diagnosticar a causa requer uma auditoria manual de cada GTM container em cada domínio, um exercício que pode demorar semanas e ainda assim pode não encontrar código injectado dinamicamente.
O cside identifica cada ID de GTM container activo em todos os domínios monitorizados, mapeia cada script a executar dentro de cada contentor, e alerta em tempo real quando um novo ID de contentor aparece ou um contentor conhecido executa um novo padrão de script. A detecção acontece na camada do browser, onde o ataque realmente reside.
O Que o cside Detecta e Como
Resposta Rápida: O cside instrumenta 100% das sessões reais de utilizadores no browser, não uma proxy amostrada. Identifica cada script a executar por carregamento de página, mapeia cada script para a sua origem e contexto de contentor, e levanta alertas quando chamadas de API de classe redirect (como window.location, window.open, ou manipulação do histórico) são detectadas a partir de scripts que não estão na lista de inventário autorizado.
A abordagem nativa do browser do cside significa que vê o ambiente de execução JavaScript completo, não apenas o tráfego de rede. A detecção é alimentada por um motor comportamental com IA que observa o que cada script faz em tempo real: a que dados acede, para onde os envia, e se o seu comportamento corresponde a padrões conhecidos de violação. Para ataques de classe redirect especificamente, a plataforma monitoriza:
- Atribuições de
window.locatione escritas delocation.replace()/location.href - Chamadas
window.open()e os URLs de destino que tentam abrir - Registo de listeners de evento em elementos DOM de alto valor (botões, campos de formulário, tags de âncora)
- Chamadas
history.pushStateehistory.replaceStateque alteram o URL navegável - Tentativas de aceder ou manipular
document.referrerou parâmetros de query URL associados a encaminhamento de afiliados ou de fluxo de retorno
Como o cside instrumenta 100% das sessões (não uma abordagem de amostragem), captura as condições de ataque precisas que tornam estes payloads difíceis de encontrar: gatilhos apenas para móvel, específicos de geo, apenas para a página de depósito que uma solução amostrada ou baseada em proxy vai estatisticamente não detectar.
Quando um novo evento de redirect é detectado a partir de uma origem de script não autorizada, o cside apresenta o contexto completo: qual script o desencadeou, qual GTM container carregou esse script, em quais páginas estava activo, e quais segmentos de utilizadores foram expostos.
Na nossa monitorização de plataformas iGaming, os sinais de classe redirect estão entre os eventos de maior severidade que apresentamos. Os operadores que os detectam consistentemente reportam que o script desencadeante estava presente há semanas antes do alerta, desviando silenciosamente um subconjunto de utilizadores móveis que depositam enquanto as métricas agregadas de conversão mascaravam a perda. O relatório IBM Cost of a Data Breach 2024 situa o custo médio global de uma violação em $4,88 milhões, mas para operadores de jogo o custo comercial do redirecionamento de jogadores não detectado é acumulado antes de qualquer acção regulatória começar.
O Que os Operadores Descobrem nas Primeiras 48 Horas
Quando executámos a primeira sessão de monitorização numa grande plataforma europeia multi-marca de jogo online no início deste ano, o pressuposto da equipa de segurança era que os seus logs server-side e WAF teriam detectado qualquer coisa séria. O que o cside encontrou nas primeiras 24 horas contou uma história diferente. No domínio inicial monitorizado da marca, a plataforma identificou actividade de redirect com alvo geográfico que não tinha aparecido em nenhum log de servidor. Scripts carregados através de tags de afiliados estavam a executar lógica de redirect condicional que apenas disparava para utilizadores móveis em geos específicas da Europa Central e Oriental. No computador, no Reino Unido, ou em qualquer sessão onde o parâmetro de referência do afiliado estava ausente, a página comportava-se exactamente como esperado. Os redirects eram invisíveis para a equipa de QA porque ninguém estava a executar QA a partir do dispositivo, localização e fonte de tráfego correctos simultaneamente.
Dentro de 48 horas, a equipa de segurança tinha um mapa completo de cada script a executar chamadas de API de classe redirect no domínio de teste, incluindo o snippet de afiliado específico responsável, os destinos-alvo, e os segmentos exactos de utilizadores afectados. O Head of Security da plataforma descreveu-o como a primeira vez que viu a sua superfície de ataque na camada do browser como um todo em vez de um domínio de cada vez. O redirect estava a correr silenciosamente por um período indeterminado antes de a monitorização começar.
Por Que a Camada de Detecção Deve Residir no Browser
As ferramentas de camada de rede e a instrumentação de camada de browser não são substitutos uma da outra. A tabela abaixo mostra o que cada abordagem pode e não pode observar num cenário de ataque de redirect.
| Capacidade | Ferramentas de camada de rede (WAF, CDN, Page Shield) | Instrumentação de camada de browser (cside) |
|---|---|---|
| Quais scripts foram pedidos | Sim | Sim |
| Quais IDs de contentor carregaram | Parcial (apenas parâmetro URL) | Sim, todos os contentores activos |
| Que tags dispararam dentro de cada contentor | Não | Sim |
| Que JavaScript executou após o carregamento de página | Não | Sim |
Chamadas window.location ou window.open | Não | Sim, com URL de destino |
| Mutações DOM e mudanças de listeners de evento | Não | Sim |
| Activação de payload apenas para móvel ou específico de geo | Não | Sim, 100% das sessões |
| Quais segmentos de utilizadores foram expostos | Não | Sim |
Esta lacuna arquitectural não é uma deficiência de nenhum fornecedor particular. É uma consequência de onde cada ferramenta opera. Um WAF fica entre o CDN e o seu servidor de origem. A instrumentação de camada de browser fica dentro do browser ao lado do código que monitoriza. Apenas uma dessas posições pode ver um redirect JavaScript a executar após o carregamento de página.
O Que os Operadores Devem Fazer Agora
Se a sua plataforma está a executar scripts de rastreamento de afiliados, um tag manager, ou qualquer JavaScript de terceiros sem monitorização contínua na camada do browser, tem um ponto cego que as ferramentas de rede não conseguem fechar. Os passos práticos são:
- Faça um inventário de cada ID de GTM container activo em todos os seus domínios, não apenas os que a sua equipa adicionou
- Mapeie cada script a executar por carregamento de página para a sua origem, contentor, e as chamadas de API que faz
- Estabeleça um inventário de scripts aprovados e configure alertas para qualquer desvio do mesmo
- Aplique cobertura de 100% das sessões, não amostragem, para que payloads com alvo geográfico e de dispositivo não possam evadir a detecção por sorte estatística
O cside fornece esta capacidade como uma camada contínua e nativa do browser em todo o seu portfólio de domínios. Monitoriza cada script de primeira, terceira e quarta parte que executa nos browsers dos seus jogadores, incluindo scripts que são carregados por outros scripts. Quando um evento de classe redirect dispara a partir de um script não autorizado, o alerta é apresentado imediatamente com o contexto de execução necessário para o conter.
Resumo
Os ataques de redirect por injecção no browser são operacionalmente invisíveis para qualquer ferramenta que não corra dentro do browser. As plataformas de jogo estão desproporcionalmente expostas por causa dos seus ambientes de scripts pesados em afiliados e do alto valor monetizável de mesmo pequenas taxas de desvio. Os logs de rede, WAFs e ferramentas de camada CDN confirmam que os scripts carregaram, não o que fizeram após carregar. A única camada de detecção que consegue observar chamadas de API de classe redirect, manipulação DOM e sequestro de listeners de evento é uma que instrumenta o runtime JavaScript directamente, com cobertura de 100% das sessões e alertas em tempo real sobre desvios de um inventário de scripts autorizado.
