Resumo: o que é skimming de cartão online
- O que é o skimming de cartões: JavaScript que lê campos de cartão no checkout e transmite os dados antes que o formulário chegue ao seu servidor.
- Os danos são reais: British Airways, Ticketmaster, Newegg, Warner Music, Segway. Perdas por incidente rotineiramente ultrapassam $100M assim que as ações coletivas chegam.
- Detetado no navegador: Você captura na sessão do navegador, não na origem. O skimmer vem de um domínio permitido e dispara antes do submit.
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
O que é skimming de cartão online?
- Skimming de cartão online
- O skimming de cartão online é um ciberataque em que JavaScript malicioso é executado no navegador de um comprador na página de pagamento de um comerciante. Enquanto o usuário digita seu número de cartão, data de validade, CVV e endereço de cobrança no formulário de pagamento, o script copia esses dados e os transmite para um servidor controlado pelo invasor, antes que o pagamento seja enviado.
O termo "skimming de cartão" tem origem na fraude física: um dispositivo de hardware fixado a um caixa eletrônico ou terminal de ponto de venda que lê a tarja magnética do cartão e registra o PIN quando um cliente o digita. O skimming de cartão online funciona com o mesmo princípio, mas não precisa de nenhum dispositivo físico. Algumas linhas de JavaScript substituem o hardware. O ataque não deixa rastro físico, pode ser executado sem ser detectado por meses e pode ser implantado em milhares de sites simultaneamente por meio de um único script de terceiros comprometido.
O Relatório Semestral de Ameaças da Visa da Primavera de 2025 identificou o skimming digital como uma das "ameaças mais prolíficas e consistentes" no ecossistema de pagamentos, observando que o programa eCommerce Threat Disruption da empresa verifica ativamente sites de comerciantes em busca de assinaturas de skimmer na América do Norte e na Europa.
Para uma visão complementar do lado de execução no navegador deste ataque, veja nosso guia detalhado sobre e-skimming.
Como os invasores implantam scripts de skimming de cartões
Os invasores precisam de execução de código na página de pagamento alvo. Eles obtêm isso por meio de pontos de entrada na cadeia de fornecimento em vez de atacar diretamente o servidor do comerciante:
- Um plugin de terceiros, extensão de CMS ou widget comprometido que o site do comerciante já carrega
- Uma atualização maliciosa enviada para uma biblioteca de análise ou gerenciador de tags hospedada em CDN
- Uma violação do painel de administração do CMS ou repositório de código do comerciante
Uma vez que controlam um arquivo JavaScript executado na página de pagamento, eles adicionam o payload de skimming. O script se conecta aos campos do formulário de pagamento. Enquanto o cliente digita, o script copia cada valor, codifica os dados e os envia via HTTPS para um domínio controlado pelo invasor, tipicamente um domínio semelhante com typosquatting projetado para se misturar nos logs de tráfego de rede. A solicitação de exfiltração nunca passa pelo servidor do comerciante.
Três propriedades tornam isso quase invisível de fora do navegador: a solicitação de saída é criptografada; o domínio de destino imita um fornecedor legítimo; e o payload é pequeno o suficiente para parecer tráfego de análise rotineiro.
Por que scanners de código em repouso não o detectam
A maioria das ferramentas de segurança de sites busca uma página, analisa o código-fonte HTML e JavaScript e sinaliza assinaturas maliciosas conhecidas. O skimming de cartão online evita essa abordagem por uma razão estrutural: o skimmer é executado no navegador real de um usuário, onde o invasor pode aplicar lógica condicional que um scanner nunca aciona.
Um script pode retornar código limpo para rastreadores headless e se ativar apenas quando detecta comportamento humano, um endereço IP real ou uma região geográfica específica. O WAF, o servidor de origem e o processador de pagamento do comerciante nunca recebem nenhuma evidência do roubo. Apenas uma camada de monitoramento executada dentro de sessões reais de visitantes pode observar o script como ele realmente se comporta.
Ataques de skimming de cartão online conhecidos
British Airways (2018). Invasores plantaram 22 linhas de JavaScript em ba.com que exfiltravam dados de pagamento para um domínio semelhante, baways[.]com. O script funcionou sem ser detectado por aproximadamente dois meses e afetou cerca de 500.000 clientes e funcionários. O Escritório do Comissário de Informação do Reino Unido emitiu uma multa inicial de £183 milhões sob o RGPD, posteriormente reduzida para £20 milhões. O caso foi uma das primeiras ações de aplicação do RGPD de alto perfil diretamente ligadas a uma falha de segurança de pagamento no lado do cliente.
Magecart (em andamento). O nome se originou de ataques visando carrinhos de compras baseados em Magento, mas agora abrange dezenas de grupos de atores de ameaça distintos usando skimming de cartão online em muitas plataformas. Os atores Magecart comprometeram fornecedores de scripts de terceiros cujas bibliotecas são executadas simultaneamente em milhares de sites de comerciantes, transformando uma única violação na cadeia de fornecimento em um evento massivo de roubo de cartões. Veja os maiores ataques Magecart já registrados.
Requisitos do PCI DSS 4.0.1 para prevenção de skimming de cartões
O PCI DSS 4.0.1 introduziu dois requisitos que abordam diretamente o skimming de cartões online. Ambos se tornaram obrigatórios em 31 de março de 2025:
O requisito 6.4.3 exige que cada script carregado em uma página de pagamento seja documentado em um inventário, autorizado com justificativa de negócios e que sua integridade seja protegida. A intenção é impedir que scripts não autorizados sejam executados onde dados do cartão são inseridos.
O requisito 11.6.1 exige um mecanismo de detecção de adulteração que alerte sobre alterações não autorizadas em scripts de páginas de pagamento e cabeçalhos HTTP que afetam a segurança, avaliado pelo menos semanalmente ou em um cronograma analisado por risco.
Auditorias manuais de scripts e varreduras pontuais não podem satisfazer esses requisitos no volume e frequência que especificam. O monitoramento automatizado e contínuo do que os scripts realmente fazem em navegadores reais é a linha de base que ambos os requisitos foram escritos para impor.
| Requisito | O que exige | Obrigatório desde |
|---|---|---|
| 6.4.3 | Inventário de scripts, autorização e integridade nas páginas de pagamento | 31 de março de 2025 |
| 11.6.1 | Detecção de adulteração com alertas para alterações nas páginas de pagamento | 31 de março de 2025 |
Como detectar o skimming de cartão online
A detecção requer visibilidade do que os scripts fazem dentro dos navegadores reais dos visitantes, não apenas a aparência do código-fonte no momento da varredura. O cside implanta um único snippet JavaScript próprio (sem proxy, sem alterações de DNS) que monitora o comportamento de scripts no nível do navegador em cada carregamento de página real.
Os sinais que o cside detecta para detecção de skimming de cartão online:
- Scripts novos ou modificados aparecendo nas páginas de pagamento sem autorização
- Ouvintes inesperados em campos de entrada que lidam com dados do cartão
- Solicitações de saída para domínios fora de uma lista de permissões autorizada
- Comportamento de script que difere entre sessões automatizadas e sessões de usuários reais
Isso produz o registro contínuo em tempo real que o PCI DSS 4.0.1 exige: um inventário de scripts autorizado para o 6.4.3 e evidências de detecção de adulteração para o 11.6.1.
Leitura relacionada:
- O que é e-skimming?
- Formjacking vs Magecart vs skimming digital
- O que são skimmers digitais?
- Guia de conformidade com os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1
Incidentes notáveis de skimming de cartões online
As divulgações seguintes são os casos de referência sempre que o skimming de cartões é discutido num contexto de PCI DSS 4.0.1 ou de segurança de aplicações web. Cada um envolveu JavaScript malicioso no checkout de um comerciante que capturou os campos do cartão antes de serem enviados para tokenização.
- British Airways (2018). ~380.000 registos de cartão skimmed durante 15 dias a partir de um script comprometido no checkout e na app móvel. Multa do ICO do Reino Unido reduzida de £183M para £20M em recurso.
- Ticketmaster UK (2018). ~40.000 clientes afetados após o widget de suporte ao cliente Inbenta, servido a partir de um CDN de terceiros, ter sido modificado para ler o formulário de pagamento.
- Newegg (2018). 15 linhas de código skimmer correram em
checkout/payment.aspxdurante 35 dias, atribuídas ao Magecart Group 4 pela RiskIQ. - Warner Music Group (2020). Compromisso de três meses de várias lojas WMG na plataforma Volusion.
- Segway (2022). Skimmer entregue via uma extensão Magento maliciosa, segundo a Malwarebytes.
- Cadeia de fornecimento Polyfill.io (2024). Após uma mudança de propriedade,
cdn.polyfill.ioserviu código malicioso a >100.000 sites que embebiam a biblioteca; a divulgação da Sansec levou a Cloudflare, Fastly e Google a intervirem. - Adobe Commerce / Magento Cosmicsting (CVE-2024-34102, 2024). Bug de desserialização XML do lado do servidor usado para plantar skimmers do lado do cliente em centenas de comerciantes Magento.
Cada incidente contornou WAFs, firewalls de rede e controlos do lado do servidor porque o skimmer foi executado no navegador do comprador, não no servidor do comerciante. Essa é exatamente a razão pela qual o PCI DSS 4.0.1 introduziu os controlos do lado do navegador nos requisitos 6.4.3 e 11.6.1.
