A principal ameaça atual às informações de cartão de crédito não é um skimmer físico; são os ataques à cadeia de suprimentos de software em sites. Os atacantes inserem JavaScript malicioso em páginas de pagamento. Uma vez injetado, esse script é programado para capturar os dados do cartão conforme são digitados em tempo real, muitas vezes sem ser detectado.
O termo Magecart é frequentemente usado como sinônimo para esse tipo de ataque. Ele tem origem nos ataques que ocorriam na plataforma Magento, popular em sites de e-commerce. O nome é uma combinação de "Magento" e "Cart" (carrinho) — referindo-se aos carrinhos de compra onde os ataques costumam acontecer.
Tanto o Magento quanto o WordPress são alvos comuns de ataques client-side. Esses ataques frequentemente miram versões mais antigas das plataformas que não foram devidamente atualizadas. Saiba mais sobre os maiores ataques Magecart da história até agora.
O Relatório Semestral de Ameaças da Visa (Primavera de 2025) identifica o skimming digital como uma das ameaças "mais prolíficas e consistentes" no ecossistema de pagamentos. O relatório destaca que o sistema de Disrupção de Ameaças em eCommerce da Visa (eTD) realiza varreduras proativas em sites de comerciantes em busca de assinaturas de skimmers na América do Norte e na Europa.
O guia Digital Skimming: How to Stay Protected da Mastercard explica como a plataforma RiskRecon deles localiza esses scripts maliciosos, rastreia as datas e durações das injeções e identifica vulnerabilidades relacionadas.
Leia o relatório da Mastercard.
Como funciona o skimming via cadeia de suprimentos
O atacante precisa ter acesso a um arquivo JavaScript na página-alvo. A forma como ele obtém esse acesso pode variar. A abordagem mais comum é conseguir acesso a um script já presente no site. Geralmente são plugins desatualizados ou sem manutenção, ou um script de terceiros ou ferramenta de marketing que foi comprometida. O atacante então altera o script para executar o ataque.
Existem variações disso, como visto no ataque à Baways (British Airways). Nesse caso, o atacante conseguiu invadir o backend e instalar um script diretamente no site da BA.
Em qualquer cenário, o script executado no lado do cliente (ou seja, no navegador) pode realizar todo tipo de ação. Em operações de skimming, as mais comuns são:
- Simplesmente copiar os campos do formulário no momento do envio ou por meio de keylogging
- Redirecionar a página de checkout para um portal de pagamento falso
- Sobrepor um
<iframe>malicioso sobre a página de pagamento original - …
Qualquer pessoa com acesso a JavaScript em uma página pode, na prática, fazer o que quiser. Esses scripts são altamente adaptáveis, dinâmicos conforme diversos critérios, e representam a forma perfeita e silenciosa de roubar dados de cartões de crédito e informações pessoais (PII).
Visão geral das soluções
Baseada em proxy
O skimming client-side é difícil de detectar justamente porque acontece fora da sua infraestrutura. Os scripts executados no navegador do seu cliente são dinâmicos, e os atacantes frequentemente comprometem ferramentas que já têm acesso legítimo.
Por isso, ver o payload real conforme ele é entregue aos usuários reais é fundamental. Sem essa visibilidade, você nunca tem certeza absoluta do que foi executado ou de onde o comprometimento começou.
Construímos nossa solução em torno de um modelo híbrido de proxy, pois é a única abordagem que oferece cobertura completa e em tempo real para frontends modernos. Todo script que chega aos seus usuários passa pelo proxy. Nossa solução de segurança para cadeia de suprimentos permite visibilidade total do payload efetivamente entregue, além de histórico completo e análise dos scripts.
Monitoramento baseado em JavaScript (Agentes)
Alguns fornecedores oferecem detecção por meio de tags JavaScript que você incorpora na sua página. Isso significa que o atacante também as vê. Pense nisso como uma ratoeira: ela pode ser vista e pode ser evitada. Se alguém está injetando scripts no seu checkout, também pode modificar ou desativar o script de proteção/monitoramento.
Ferramentas apenas de detecção também tendem a disparar alertas depois que os dados já foram exfiltrados. Acreditamos que prevenção é melhor.
Crawlers
Ferramentas baseadas em crawlers funcionam simulando visitas ao seu site e capturando os scripts e recursos carregados durante essa visita. O ponto crítico é que elas não necessariamente recebem o mesmo payload de script que um usuário real receberia. Elas "imitam" um usuário.
Scripts são dinâmicos por natureza, e os atacantes usam isso a seu favor. Na teoria e na prática, esses crawlers são identificáveis e, portanto, evitáveis.
Crawlers são úteis para varreduras superficiais. Mas skimmers não operam na superfície.
Content Security Policy (CSP)
Content Security Policy (CSP) é um recurso do navegador que permite aos proprietários de sites definir quais fontes de conteúdo (como scripts) têm permissão para carregar em uma página. Quando configurada corretamente, a CSP pode ajudar a bloquear código de terceiros não autorizado ou inesperado, restringindo as origens dos scripts.
É um controle preventivo valioso, especialmente para reduzir a exposição a injeções de scripts inline ou carregamentos de domínios desconhecidos. Recomendamos o uso de CSP apenas como uma camada. Porque a CSP não consegue ver o payload do script.
Em nossas palestras e apresentações, costumamos usar o seguinte slide para ilustrar a CSP:
Você tem 2 caixas. Uma contém um filhote de cachorro, a outra uma bomba. Qual é qual…? Isso é CSP.
Na nossa página de comparação, detalhamos as 4 abordagens apresentadas aqui.
Um resumo rápido das soluções
Scripts carregados no navegador do seu cliente podem acessar campos de entrada, modificar conteúdo, enviar dados para outros destinos e muito mais. São dinâmicos, frequentemente provenientes de terceiros, e podem ser alterados sem o seu conhecimento.
É por isso que o skimming client-side é tão eficaz. E por que preveni-lo exige mais do que varreduras superficiais.
Por que o caminho de entrega é tão importante?
Porque é a única forma de ver o que realmente chega ao usuário. Scripts são dinâmicos. Os atacantes podem alterá-los a qualquer momento, muitas vezes de forma condicional. Se você não está no caminho de entrega, está dependendo de snapshots ou suposições. Estar no caminho significa que você vê cada requisição, de cada sessão, em tempo real, e pode agir antes que qualquer coisa perigosa seja executada.
Qual é a melhor forma de prevenir esses ataques?
O método mais eficaz atualmente é o monitoramento de scripts baseado em proxy da cside. Ele inspeciona cada script antes que chegue ao navegador, verifica sua integridade e bloqueia código malicioso em tempo real. Funciona em todas as sessões de usuário e oferece visibilidade completa, registro de logs e cobertura de conformidade.
O monitoramento baseado em JavaScript (Agentes) é uma boa opção?
Pode ajudar a detectar algumas ameaças, mas é executado dentro do mesmo ambiente que os atacantes visam. Se um atacante consegue injetar um skimmer, provavelmente também consegue desativar ou contornar o script de monitoramento. É útil, mas não suficiente por si só.
Um crawler é uma boa opção?
Crawlers simulam visitas ao seu site e registram os scripts visíveis. São bons para varreduras periódicas, mas não operam dentro de sessões reais. Se um skimmer só está ativo sob determinadas condições (como um usuário logado ou um intervalo de IP específico), os crawlers não o detectarão.
CSP é uma boa opção?
A CSP (Content Security Policy) pode reduzir riscos limitando de onde os scripts têm permissão para carregar. Mas ela não analisa o que um script faz depois de carregado. É uma camada útil, mas não é um sistema sólido de detecção nem de prevenção.
