Resumo
- O skimming de cartão online é JavaScript malicioso na página de pagamento de um comerciante que copia dados do cartão de pagamento enquanto o cliente os digita.
- Os invasores colocam o script comprometendo um plugin de terceiros, uma biblioteca de análise ou um gerenciador de tags que o site já carrega.
- Os dados roubados saem do navegador diretamente para um servidor controlado pelo invasor. Seu backend, WAF e processador de pagamento nunca os veem.
- O Relatório Semestral de Ameaças da Visa da Primavera de 2025 identifica o skimming digital como "uma das ameaças mais prolíficas e consistentes" no ecossistema de pagamentos.
- Os requisitos PCI DSS 4.0.1 6.4.3 e 11.6.1, obrigatórios desde 31 de março de 2025, existem especificamente para combater esse tipo de ataque.
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:
