Resumo Rápido
- E-skimming é um ataque cibernético em que código é injetado no site de um lojista. Usuários que visitam uma página de pagamento têm as suas informações roubadas por código malicioso que monitoriza e "skima" os dados do cartão digitados.
- O e-skimming captura dados antes ou durante o envio do pagamento. As informações são roubadas antes de chegarem ao perímetro de criptografia ou à segurança do servidor.
- Para prevenir o e-skimming, use uma ferramenta como o cside, que monitoriza o comportamento de scripts de terceiros e alerta sobre atividades suspeitas.
- Como alternativa, use controlos do navegador como CSP e SRI para limitar manualmente quais scripts de terceiros podem aceder às páginas de pagamento.
- Os Requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 (obrigatórios desde 31 de março de 2025) exigem que os lojistas inventariem cada script nas páginas de pagamento e monitorizem alterações não autorizadas, pressão regulatória direta para combater o e-skimming.
O que é e-skimming?
- E-skimming
- E-skimming (também chamado de "web skimming") é um ataque cibernético em que um agente malicioso injeta um trecho de código no site de um lojista. Quando um usuário acede à página de pagamento, o código malicioso monitoriza os campos do formulário para capturar os dados do cartão, que são então enviados a um servidor controlado pelo atacante para uso fraudulento.
O e-skimming é um ataque client-side em que JavaScript malicioso injetado na página de pagamento de um lojista captura números de cartão, datas de validade, CVCs e endereços de faturação enquanto os usuários os digitam, antes de os dados chegarem a qualquer criptografia no servidor. Os dados roubados são enviados em tempo real para um servidor controlado pelo atacante e vendidos em mercados da dark web ou usados diretamente para fraude com cartão. O e-skimming é o equivalente digital de um skimmer físico instalado num caixa eletrónico, exceto que é invisível, puramente de software e pode operar sem ser detetado durante meses.
Para comparar, o skimming físico de cartões ocorre quando um dispositivo é instalado num caixa eletrónico ou teclado de pagamento. Um cliente desavisado usa o cartão para fazer uma compra, e o dispositivo captura as informações do cartão de crédito e o PIN digitado. O dispositivo é construído para passar despercebido pelo pessoal do estabelecimento.
Da mesma forma, as injeções de código de e-skimming são concebidas para ser invisíveis. Muitas vezes permanecem nas páginas de pagamento durante semanas (e em alguns casos meses) antes de os proprietários dos sites se aperceberem.
Que dados são visados nos ataques de e-skimming
| Tipo de Dado | Preço Médio na Dark Web |
|---|---|
| Cartão de Crédito dos EUA | $10 a $100 |
| Conta Gmail | $60 |
| Credenciais de Acesso Bancário | $200 a $1.000 |
| Credenciais de Acesso Corporativo | $100 a $10.000 |
Embora o e-skimming se refira mais comummente ao roubo de informações de cartão de crédito, o web skimming também pode abranger, de forma mais ampla, ataques que visam estas informações:
- Credenciais de login (nome de usuário, e-mail, palavra-passe)
- Informações pessoais (endereço, nome legal, números de telefone)
O e-skimming é um ataque client-side?
Sim. Web skimming, e-skimming ou digital skimming (nomes diferentes para o mesmo vetor de ameaça) são uma forma de ataque client-side.
Geralmente são ataques bem preparados e sofisticados, uma especialidade de certas comunidades de hackers que realizam ataques Magecart.
Existem outros ataques client-side, como phishing com sobreposições de interface ou páginas de checkout falsas.
Durante o web skimming, os atacantes canalizam os dados roubados para o seu próprio servidor, geralmente através de um domínio que se assemelha bastante ao do lojista legítimo. Este estilo de ataque foi usado contra o Ticketmaster e a British Airways, entre outros.
Que sites são vulneráveis ao e-skimming?
Qualquer site que trabalhe com scripts de terceiros, especialmente quando estes correm em páginas de login ou checkout. Sites construídos em Magento, WooCommerce ou outras plataformas low-code são especialmente vulneráveis.
Embora as próprias plataformas sejam seguras e as suas equipas de segurança trabalhem ativamente para corrigir vulnerabilidades conhecidas, essas plataformas são frequentemente usadas por usuários não técnicos, que têm menos probabilidade de perceber que um ataque está a ocorrer.
Previna o e-skimming com segurança client-side automatizada do cside
Como o e-skimming funciona e onde as coisas correm mal
Para entender como os e-skimmers operam, precisamos de analisar como funcionam os pagamentos online.
Quando os compradores enchem o carrinho e estão prontos para finalizar o pedido, chegam à página de pagamento. Aí, preenchem os campos do formulário. Depois de o pagamento ser submetido, os dados são encriptados e enviados ao lojista e à operadora do cartão. Se a transação for aprovada, o processo de entrega começa.
Assim que o pagamento é submetido, as informações ficam protegidas por encriptação, controlos de servidor, segurança de API e outras camadas de defesa. Infelizmente, o e-skimming captura as informações antes/durante a submissão do pagamento. O código malicioso monitoriza as teclas digitadas enquanto o usuário introduz as informações. Esta técnica específica, interceptar campos de formulário para capturar dados à medida que são digitados, é conhecida como formjacking.
Como os hackers injetam código de e-skimming
Quando um usuário acede a uma página do seu site, o navegador carrega uma combinação de código. Parte é código próprio criado pela sua equipa (ou escrito pela plataforma que usa, como Shopify ou WooCommerce). Mas o seu site também serve código de terceiros.
Para sites de e-commerce, isto inclui plugins e scripts de terceiros:
- Ferramentas de analytics (como Amplitude)
- Ferramentas promocionais (como captura de e-mails para newsletter)
- Construtores de kits de produtos
- Rastreamento de anúncios (Meta, Google)
E muitas outras ferramentas de terceiros essenciais para sites de e-commerce.
Os scripts de terceiros são um ponto de entrada para web skimming
Cada script de terceiro é um ponto de entrada para atacantes. Podem ser infiltrados por diversos métodos:
- Domínios expirados: quando um domínio antigo não é renovado, os atacantes podem comprá-lo e alterar o código. Se o seu site vai buscar código a esse domínio, o código malicioso será carregado.
- Ataques à cadeia de fornecimento: se um terceiro de confiança for hackeado, o seu script pode espalhar código malicioso para o seu site.
- Através de gestores de tags: se os atacantes obtiverem acesso ao Google Tag Manager, podem injetar código que vai diretamente para o seu site em produção sem qualquer revisão. A atividade desse script ficará oculta, pois estará agrupada com vários outros scripts.
- Credenciais expostas: credenciais roubadas podem conceder aos atacantes acesso interno aos seus sistemas. Em vez de tentarem invadir o cofre (os seus servidores), podem optar por injetar código no seu site.
Individualmente, ferramentas de terceiros consolidadas são seguras e apresentam risco mínimo. Mas os sites modernos têm dezenas de scripts de terceiros. Um relatório do Web Almanac constatou que a mediana de domínios de terceiros num site é 23. E esses scripts de terceiros carregam mais scripts (scripts de quarta parte) para os ajudar no processamento de dados.
Um chatbot (script de terceiro) pode carregar uma ferramenta de análise de documentos para ajudar clientes com tickets de suporte, analisando os seus PDFs. Nunca autorizou diretamente essa ferramenta de análise de documentos, mas ela é servida no seu site (e acede a informações sensíveis).
Talvez comece a perceber o problema: o seu site acaba com dezenas de scripts que podem injetar código sem que ninguém os monitorize.
O que os atacantes fazem com os dados obtidos por e-skimming
Qual é o perigo, afinal? No cenário ideal para o atacante: cria um script que lhe permite ver o que os usuários introduzem no formulário de pagamento. Bingo. Agora vê os dados pessoais, o número do cartão, a data de validade e o código CVC.
Se conseguir copiar e exfiltrar essas informações para o seu próprio servidor, o saque está garantido. Pode vender essas informações na dark web ou usar os dados do cartão diretamente para cometer fraudes.
Como os lojistas online podem prevenir o e-skimming
1. Monitorize scripts de terceiros: que dados eles acedem e para onde os enviam?
A monitorização de scripts em tempo real é essencial. Ferramentas que observam scripts de terceiros e o seu comportamento emitem um alerta quando é identificada uma atividade suspeita. Por exemplo, se um script de analytics começar de repente a ler dados de formulários e a enviá-los para um servidor na Rússia, pode estar perante um ataque client-side.
A plataforma cside monitoriza scripts de terceiros para verificar a que dados eles têm acesso e alerta imediatamente caso o acesso a dados mude.
2. Limite quais scripts correm nas páginas de pagamento
Para os lojistas, o primeiro passo é saber quais scripts correm nas páginas de pagamento. Como medida de precaução, garanta que apenas os scripts necessários correm ali. Tudo o que não seja estritamente necessário para pagamento ou prevenção de fraudes: elimine.
3. Use o cside para governação de scripts de terceiros
Muitos sites permitem por defeito que scripts de terceiros vão diretamente para o site em produção. As equipas de marketing e os programadores querem atualizações rápidas para melhorar a funcionalidade. Mesmo as empresas que verificam cada script aprovam-nos uma vez e raramente os revêm.
Pode parecer um trabalho manual enorme rever cada script adicionado, mas uma ferramenta como o cside rastreia automaticamente cada novo script adicionado e fornece um resumo escrito por IA e uma pontuação de risco para que possa aprovar rapidamente. Todos os scripts são mantidos num "inventário ao vivo" que as equipas de conformidade de privacidade ou de segurança podem gerir com facilidade.
4. Implemente controlos de segurança do navegador: CSP e SRI
Os ataques de e-skimming acontecem no navegador, por isso podemos usar aí uma camada defensiva. O CSP e o SRI proporcionam isso. É certo que não resolvem tudo, mas criam mais visibilidade.
Um CSP restrito determina que fontes podem carregar scripts e a que endpoints podem aceder. O conteúdo do script em si não é verificado, mas fluxos de dados indesejados são detetados e podem ser bloqueados. Comece com Content-Security-Policy-Report-Only para testar se tudo continua a funcionar corretamente.
O SRI adiciona um hash aos ficheiros: é assim que se verifica se um script foi modificado na origem ou durante a transferência. Isto torna muito mais difícil espalhar código malicioso através de uma atualização ou de um fornecedor comprometido. Funciona sobretudo para scripts estáticos. Mas a atualização automática de scripts de terceiros quebra a verificação do hash.
Por que razão a segurança web tradicional não deteta o e-skimming
O malware não corre no servidor do lojista. Corre no navegador do cliente com os mesmos direitos e privilégios do código do próprio lojista.
O JavaScript é aceite e executado no DOM. As ferramentas de segurança web tradicionais frequentemente não têm visibilidade sobre isto. Mesmo ferramentas de defesa client-side como a Content Security Policy analisam apenas a origem de cada script. Se uma fonte confiável estiver a servir código malicioso, as políticas de segurança de conteúdo não detetarão nem bloquearão esse ataque.
O que o PCI DSS 4.0.1 exige para prevenir o e-skimming
O PCI DSS 4.0.1 introduziu dois requisitos que visam diretamente o e-skimming, ambos obrigatórios desde 31 de março de 2025:
Requisito 6.4.3: Inventário e autorização de scripts nas páginas de pagamento. Cada script carregado numa página de pagamento deve estar documentado num inventário, autorizado com uma justificação de negócio e com a sua integridade protegida. Os lojistas devem ser capazes de confirmar que nenhum script não autorizado corre no checkout. As revisões manuais falham na prática: os scripts são muitas vezes adicionados por equipas de marketing através de gestores de tags e nunca revistos pela equipa de segurança.
Requisito 11.6.1: Mecanismo de deteção de adulteração nas páginas de pagamento. Os lojistas devem implementar um mecanismo que deteta alterações não autorizadas nos cabeçalhos HTTP e no conteúdo das páginas de pagamento. O mecanismo deve alertar sobre alterações e deve avaliar a página pelo menos uma vez a cada sete dias (ou conforme definido por uma análise de risco direcionada). Um script de terceiro comprometido que modifica o comportamento do formulário satisfaz a definição de "alteração não autorizada".
Juntos, estes requisitos significam que as revisões manuais de scripts e as auditorias periódicas já não são suficientes. A monitorização client-side automatizada e contínua (como a que o cside fornece) é o que o PCI DSS 4.0.1 foi escrito para exigir.
Como é a conformidade com o 6.4.3 e o 11.6.1 na prática?
A conformidade exige três elementos a funcionar continuamente em cada página de pagamento:
- Um inventário de scripts em tempo real que capture cada script próprio e de terceiros, o seu domínio de origem e a sua justificação de negócio.
- Verificação de integridade que confirme que cada script não foi modificado desde a sua autorização.
- Deteção de adulteração que alerte dentro da janela de avaliação exigida sempre que for detetada uma alteração não autorizada ao conteúdo da página ou aos cabeçalhos.
Folhas de cálculo manuais e revisões mensais não conseguem cumprir estes requisitos em escala. Ferramentas automatizadas que monitorizam a execução real do navegador (observando o que os scripts realmente fazem, não apenas o que o seu código-fonte diz) são o caminho prático para a conformidade.
| Requisito PCI DSS 4.0.1 | O que exige | Data de vigência |
|---|---|---|
| 6.4.3 | Inventário, autorização e integridade de scripts nas páginas de pagamento | 31 de março de 2025 |
| 11.6.1 | Mecanismo de deteção de adulteração com alertas para alterações nas páginas de pagamento | 31 de março de 2025 |
Leitura relacionada:
