Os ataques de data skimming roubam informações de cartões de pagamento diretamente dos navegadores dos seus clientes. Estes ataques operam inteiramente no lado do cliente, o que significa que o seu WAF, SIEM e logs de servidor não veem nada de anormal enquanto os números de cartão fluem para servidores controlados pelos invasores. De acordo com uma pesquisa da DataDome, os ataques Magecart comprometeram mais de 2 milhões de sites em todo o mundo desde o primeiro ataque executado em massa em 2015.
A cside monitora os scripts de terceiros à medida que executam em sessões reais de navegador, detetando a exfiltração de dados não autorizada e as alterações de scripts em menos de 60 segundos, em média. Este artigo explica o que é a proteção contra data skimming, como estes ataques funcionam e o que você pode fazer para os travar.
Principais conclusões: o que é a proteção contra data skimming para e-commerce
- A proteção contra data skimming monitora os scripts executados no navegador para detetar e bloquear o roubo de pagamentos antes que os dados do cartão cheguem aos invasores.
- Os ataques Magecart e de formjacking injetam JavaScript malicioso nas páginas de checkout, operando inteiramente no lado do cliente, onde as ferramentas de segurança de servidor não os conseguem ver.
- Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 agora exigem inventário de scripts, monitoramento de integridade e deteção de alterações nas páginas de pagamento.
- A cside automatiza o monitoramento de scripts, deteta alterações não autorizadas e gera relatórios prontos para auditoria que os QSAs aceitam para conformidade com o PCI.
- Ferramentas de segurança tradicionais como WAFs e CSPs não conseguem detetar o comportamento dos scripts em runtime, deixando as páginas de checkout vulneráveis a ataques à cadeia de suprimentos.
O que é o data skimming no e-commerce?
O data skimming é um ataque baseado no navegador em que JavaScript malicioso captura os dados do cartão de pagamento à medida que os clientes os introduzem nas páginas de checkout. O ataque acontece no navegador do cliente depois de o seu servidor entregar uma página limpa. A sua infraestrutura de backend vê uma transação normal enquanto o invasor recebe uma cópia de cada tecla digitada.
O nome "Magecart" refere-se a vários grupos de hackers que foram pioneiros nesta técnica, visando originalmente o software de carrinho de compras Magento. Hoje, o termo descreve qualquer ataque de web skimming que injeta código malicioso em scripts legítimos de terceiros ou diretamente nas páginas de pagamento.
Os invasores normalmente obtêm acesso através de um de três pontos de entrada: comprometimento direto do site via vulnerabilidades do CMS, ataques à cadeia de suprimentos contra fornecedores terceiros, ou buckets de armazenamento na nuvem mal configurados que contêm recursos do site. Uma vez lá dentro, implantam código de skimming que se mistura com os scripts legítimos de processamento de pagamentos.
Como funcionam os ataques de data skimming?
Os ataques de data skimming seguem um processo de três fases: infiltração, implantação e exfiltração. Compreender cada fase ajuda-o a identificar onde a proteção é necessária.
Infiltração: como os invasores obtêm acesso
Os invasores comprometem os sites diretamente ao explorar vulnerabilidades em sistemas de gestão de conteúdo ou plataformas de e-commerce. Isto dá-lhes acesso para modificar o código do site sem acionar alertas do lado do servidor.
Os ataques à cadeia de suprimentos visam serviços de terceiros em vez do seu site diretamente. Quando você carrega recursos de um fornecedor de análise comprometido, de um fornecedor de chatbot ou de uma biblioteca de pagamentos, o código malicioso executa ao lado da funcionalidade legítima. Uma única violação num fornecedor terceiro pode comprometer milhares de sites a jusante.
Implantação: como o código de skimming é instalado
Assim que os invasores têm acesso, injetam o código de skimming usando várias técnicas. A injeção de JavaScript insere código malicioso que opera ao lado do processamento de pagamentos legítimo. A clonagem de campos de formulário cria duplicados invisíveis que capturam os dados à medida que os clientes os digitam.
Ataques avançados substituem formulários de pagamento inteiros por versões fraudulentas visualmente idênticas. Para evitar a deteção, os invasores ofuscam o seu código usando codificação Base64, fragmentação de código e nomes de domínio de aparência legítima como "google-analytics.net" em vez de "google-analytics.com".
Exfiltração: como os dados roubados saem do navegador
Os dados de pagamento capturados são transmitidos para servidores controlados pelos invasores através de transmissão direta ou de exfiltração furtiva. Alguns skimmers armazenam os dados recolhidos no armazenamento do navegador e transmitem-nos em pequenos lotes ou quando o utilizador sai da página. Isto torna a deteção mais difícil porque a transferência de dados não ocorre durante o próprio processo de checkout.
O que é a proteção contra data skimming?
A proteção contra data skimming refere-se a controlos de segurança que monitoram, detetam e bloqueiam o comportamento não autorizado de scripts nos navegadores dos seus visitantes. Ao contrário da segurança do lado do servidor, que para na fronteira da rede, a proteção do lado do cliente observa o que os scripts realmente fazem à medida que executam.
Uma proteção eficaz contra data skimming inclui gestão de inventário de scripts, monitoramento de comportamento em tempo real, deteção de alterações e capacidades de aplicação. A cside recolhe mais de 250 sinais de navegador e dispositivo, monitora o payload de cada script de terceiros em sessões reais de visitantes e alerta a sua equipa quando os scripts tentam aceder aos campos do formulário de pagamento ou exfiltrar dados para endpoints externos.
Por que as ferramentas de segurança tradicionais ignoram o data skimming
Os WAFs inspecionam o tráfego na fronteira do servidor. Não conseguem ver o JavaScript a executar no lado do cliente, os dados a saírem do navegador através de chamadas de scripts de terceiros, ou os ataques que visam segmentos de utilizadores específicos com base na geografia ou no valor do carrinho.
As Content Security Policies (CSP) restringem quais domínios podem carregar scripts, mas não conseguem monitorar o comportamento dos scripts depois de carregados. Se um fornecedor confiável for comprometido, o código malicioso executa a partir de um domínio aprovado. A CSP não vê nada de errado porque a origem permanece na lista de permissões.
Por que os sites de e-commerce precisam de proteção contra data skimming
As páginas de checkout de e-commerce modernas carregam dezenas de scripts de terceiros para análise, marketing, chatbots e processamento de pagamentos. Dados do HTTP Archive mostram que o site médio usa 23 scripts de terceiros, e cada um representa um ponto de entrada potencial para os invasores.
A British Airways sofreu um ataque Magecart que comprometeu os dados de pagamento de 380.000 clientes, resultando numa multa de 20 milhões de libras ao abrigo do GDPR. A Ticketmaster foi violada através de um serviço de chatbot terceiro comprometido, afetando mais de 800 sites de e-commerce que usavam o mesmo fornecedor. Estes ataques passaram despercebidos durante semanas ou meses enquanto os dados dos cartões fluíam para os invasores.
Requisitos do PCI DSS 4.0.1 para a segurança das páginas de pagamento
Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 tornaram-se obrigatórios em 2025-03-31. O requisito 6.4.3 exige que as organizações mantenham um inventário completo e autorizado de todos os scripts nas páginas de pagamento e documentem o propósito e a integridade de cada script.
O requisito 11.6.1 exige mecanismos de deteção de alterações e adulteração para alertar o pessoal sobre modificações não autorizadas dos scripts das páginas de pagamento. A cside satisfaz ambos os requisitos automaticamente: inventaria cada script em sessões reais de visitantes, gera justificações escritas por IA para cada script, monitora os cabeçalhos em tempo real e produz relatórios prontos para auditoria aceites pelos QSAs. A VikingCloud validou a cside para estes requisitos.
Como implementar a proteção contra data skimming
A implementação da proteção contra data skimming começa por ganhar visibilidade sobre quais scripts executam atualmente nas suas páginas de pagamento. Você não consegue proteger o que não consegue ver.
Passo 1: crie um inventário de scripts
Documente cada script de terceiros em execução nas suas páginas de checkout. Para cada script, registe o seu propósito, os dados a que consegue aceder e as práticas de segurança do fornecedor. Este inventário forma a linha de base para detetar alterações não autorizadas.
Passo 2: implemente o monitoramento do lado do cliente
Adicione um script de monitoramento leve às suas páginas. A cside implementa-se através de um único snippet JavaScript adicionado ao head da sua página. Nenhum tráfego passa pela infraestrutura da cside, não há proxy reverso, nenhuma dependência de CDN e nenhuma alteração de configuração de DNS necessária. O snippet executa diretamente nos navegadores dos seus visitantes.
Passo 3: configure alertas e aplicação
Configure alertas para alterações não autorizadas de scripts, adições de novos scripts e transmissão suspeita de dados a partir das páginas de pagamento. Os ataques Magecart modificam scripts confiáveis existentes ou injetam novos. Os alertas em tempo real garantem que a sua equipa fica a saber das alterações em segundos, não depois de um relatório de violação.
Limitações das abordagens comuns de proteção
Compreender o que cada método de proteção não consegue fazer ajuda-o a construir uma defesa em camadas.
Limitações da proteção apenas com CSP
A CSP controla quais scripts podem carregar, mas não o que fazem depois de carregados. Um script de fornecedor comprometido executa a partir de um domínio aprovado. A CSP também tem dificuldades com scripts dinâmicos e código inline gerado em runtime.
Limitações das soluções baseadas em scanners
Os scanners verificam o seu site periodicamente, muitas vezes diária ou semanalmente. Os ataques que visam sessões de utilizadores específicas (pedidos de alto valor, certas geografias) escapam à deteção porque o scanner vê uma página limpa. Os scanners também não conseguem bloquear os ataques em curso, uma vez que detetam as ameaças depois do facto.
Limitações do registo do lado do servidor
Os logs de servidor registam as requisições recebidas e as respostas enviadas. O data skimming acontece inteiramente no lado do cliente. Os dados de cartão roubados vão diretamente do navegador do cliente para o servidor do invasor sem tocar na sua infraestrutura. Os seus logs mostram uma transação de checkout normal enquanto a violação ocorre.
Em conclusão: como a proteção contra data skimming protege os checkouts de e-commerce
A proteção contra data skimming monitora os scripts executados no navegador para detetar e bloquear o roubo de pagamentos. Estes ataques exploram a lacuna entre a segurança do lado do servidor e a execução de código do lado do cliente, operando no único lugar que as suas ferramentas existentes não conseguem ver.
A cside dá à sua equipa visibilidade total do comportamento dos scripts de terceiros nas páginas de checkout. Adicione um script leve ao seu site para começar a monitorar scripts, detetar ataques Magecart e gerar imediatamente evidências de conformidade com o PCI DSS 4.0.1. Para começar com a cside, marque uma demonstração.
