skimmer loja virtualroubo de cartão no checkoutmagecartpci dss 6.4.3 11.6.1

Skimmer no checkout: como um script rouba o cartão da sua loja

Um skimmer é um script escondido na página de pagamento que copia o cartão enquanto o cliente digita. Ele roda no navegador do comprador, por isso firewall e WAF da loja não o enxergam. A proteção está em listar e autorizar cada script do checkout, conferir alterações na página e usar a página de pagamento do gateway.

Por Equipe CyberArmor26 de março de 2026

Como um script rouba o cartão no checkout da loja virtual?

A página de pagamento de uma loja virtual carrega vários scripts: o da própria plataforma, o do gateway, o de análise de tráfego, o do chat, o de anúncios. Cada um roda dentro do navegador do comprador e consegue ler o que ele digita.

O criminoso aproveita isso. Ele invade a loja por um plugin desatualizado, uma falha da plataforma ou uma senha de administrador vazada. Depois insere um script a mais no checkout. O cliente compra normalmente, recebe o produto, e os dados do cartão vão também para o criminoso. A loja só descobre quando o banco aponta a origem das fraudes.

O prejuízo para o negócio vai além do estorno. A loja pode perder a confiança do cliente e entrar em atrito com o gateway. Pela LGPD, art. 46, quem trata dados pessoais deve adotar medidas de segurança técnicas e administrativas para protegê-los. O art. 48 da mesma lei manda o controlador comunicar à ANPD e ao titular o incidente que possa acarretar risco ou dano relevante.

O que o skimmer com WebRTC mostrou em 2026?

Em 24 de março de 2026, a empresa de segurança para comércio eletrônico Sansec descreveu um skimmer que usa WebRTC, a tecnologia de chamadas de vídeo do navegador, para receber o código malicioso e enviar os dados roubados. Segundo a Sansec, foi a primeira vez que ela viu WebRTC usado para esse fim.

A escolha tem motivo. A CSP (política de segurança de conteúdo) é o cabeçalho que diz ao navegador para quais endereços a página pode enviar dados. A Sansec explica que a diretiva connect-src cobre as requisições comuns da página, mas não as conexões WebRTC. O tráfego ainda sai criptografado por UDP, fora do protocolo HTTP. A conexão vai do navegador do comprador direto para um servidor do atacante.

A Sansec aponta como entrada mais provável uma falha chamada PolyShell, que permite enviar arquivos sem login a lojas Magento e Adobe Commerce vulneráveis, e diz que não há correção oficial para as versões de produção. A lição vale para qualquer plataforma: o skimmer muda de técnica, e a loja precisa controlar o que roda no checkout.

Firewall ou WAF resolvem esse problema?

Não resolvem sozinhos. O firewall e o WAF (firewall de aplicação web) ficam na frente do servidor da loja e analisam o que chega até ele. Eles podem barrar parte das tentativas de invasão, como o envio de arquivos maliciosos. Só que o skimmer, uma vez inserido, roda no computador do comprador. Os dados do cartão saem do navegador do cliente para o servidor do criminoso, sem passar pela rede da loja.

Pelo mesmo motivo, isolar a rede dos sistemas de pagamento ou vigiar conexões WebRTC na empresa não protege o checkout. A defesa precisa olhar para o conteúdo da página que o cliente recebe.

O que o PCI DSS pede para os scripts da página de pagamento?

O PCI DSS é o padrão de segurança do setor de cartões. O PCI SSC, conselho que mantém o padrão, publicou em 10/03/2025 um guia sobre segurança da página de pagamento e prevenção de e-skimming. Segundo o conselho, os requisitos 6.4.3 e 11.6.1 buscam garantir que os scripts da página de pagamento sejam autorizados, tenham a integridade conferida e sejam acompanhados contra adulteração, incluindo os cabeçalhos HTTP que afetam a segurança.

O próprio conselho informou, em episódio do seu podcast, que esses requisitos passaram a ser obrigatórios em 31 de março de 2025. No mesmo episódio, explicou que eles saíram do questionário simplificado SAQ A, voltado a lojas que usam a página ou o iframe do provedor de pagamento. Em troca, essas lojas precisam confirmar que o site não está suscetível a ataques por script, seja com técnicas como as dos dois requisitos, seja com a confirmação do provedor que fornece o iframe.

Como saber se sua loja tem um script roubando cartão?

Comece pelo inventário. Abra a página de pagamento e liste todos os scripts que ela carrega, de onde vêm e para que servem. Qualquer item sem dono e sem justificativa deve sair.

Depois, organize o controle em quatro passos:

Autorização. Mantenha a lista de scripts aprovados, com o motivo de cada um e quem aprovou.
Integridade. Para scripts de terceiros que não mudam a cada dia, use o atributo integrity, recurso chamado SRI (integridade de sub-recurso). A documentação da MDN explica que o navegador compara o arquivo baixado com um hash definido pela loja e recusa o que não bater.
Conferência de alteração. Compare periodicamente a página de pagamento e seus cabeçalhos com a versão aprovada e investigue qualquer diferença.
Menos scripts no checkout. Retire do checkout chat, pixels de anúncio e ferramentas de teste. Sempre que possível, use a página de pagamento ou o iframe do gateway, para que o cartão seja digitado fora do código da loja.

Mantenha também a plataforma e os plugins atualizados, e proteja o painel administrativo com MFA (autenticação em dois fatores). É por aí que o script costuma entrar.

Por onde começar na sua empresa?

Faça hoje o inventário dos scripts da página de pagamento e pergunte ao seu gateway qual modelo de integração reduz o código da loja no checkout. Em seguida, defina quem aprova novos scripts e com que frequência a página é conferida.

Os analistas da CyberArmor avaliam a loja no Pentest de aplicação, que testa o checkout como um atacante faria, e no Raio-X do código, projeto de 2 a 3 semanas que revisa plataforma, plugins e scripts de terceiros. Para conversar sobre a sua loja, fale com um especialista.

Fontes