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 suas informações roubadas por código malicioso que monitora 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 monitora o comportamento de scripts de terceiros e alerta sobre atividades suspeitas.
- Como alternativa, use controles do navegador como CSP e SRI para limitar manualmente quais scripts de terceiros podem acessar as páginas de pagamento.
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 acessa a página de pagamento, o código malicioso monitora 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.
Para comparar, o skimming físico de cartões ocorre quando um dispositivo é instalado em um 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 é projetado para ser invisível, passando despercebido pela equipe do estabelecimento.
Da mesma forma, as injeções de código de e-skimming são projetadas para ser invisíveis. Muitas vezes permanecem nas páginas de pagamento por semanas (e em alguns casos meses) antes que os proprietários dos sites percebam.
Quais 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 comumente ao roubo de informações de cartão de crédito, o web skimming também pode abranger ataques que visam estas informações:
- Credenciais de login (nome de usuário, e-mail, senha)
- Informações pessoais (endereço, nome completo, 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, com comunidades específicas de hackers especializadas em realizar 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 direcionam os dados roubados para seu próprio servidor, geralmente por meio de um domínio que se assemelha bastante ao do lojista legítimo. Esse estilo de ataque foi usado contra o Ticketmaster e a British Airways, entre outros.
Quais sites são vulneráveis ao e-skimming?
Qualquer site que trabalhe com scripts de terceiros, especialmente quando eles rodam 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 suas equipes 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á ocorrendo.
Previna o e-skimming com segurança client-side automatizada do cside
Como o e-skimming funciona e onde as coisas dão errado
Para entender como os e-skimmers operam, precisamos analisar como os pagamentos online funcionam.
Quando os compradores enchem o carrinho e estão prontos para finalizar o pedido, eles chegam à página de pagamento. Lá, preenchem os campos do formulário. Após o envio do pagamento, os dados são criptografados 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 é enviado, as informações são protegidas por criptografia, controles de servidor, segurança de API e uma série de outros processos de defesa. Infelizmente, o e-skimming captura as informações antes/durante o envio do pagamento. O código malicioso monitora as teclas digitadas enquanto o usuário está inserindo as informações.
Como hackers injetam código de e-skimming
Quando um usuário acessa uma página do seu site, o navegador carrega uma combinação de código. Parte é código próprio criado pela sua equipe (ou escrito pela plataforma que você usa, como Shopify ou WooCommerce). Mas o seu site também serve código de terceiros.
Para sites de e-commerce, isso 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.
Scripts de terceiros são um ponto de entrada para web skimming
Cada script de terceiro é um ponto de entrada para atacantes. Eles podem ser infiltrados por diversos métodos:
- Domínios expirados: quando um domínio antigo não é renovado, atacantes podem comprá-lo e alterar o código. Se o seu site busca código desse domínio, o código malicioso será carregado.
- Ataques à cadeia de suprimentos: se um terceiro confiável for hackeado, o script dele pode espalhar código malicioso para o seu site.
- Por meio de gerenciadores de tags: se atacantes obtiverem acesso ao Google Tag Manager, podem injetar código que vai direto para o seu site em produção sem nenhuma 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 tentar invadir o cofre (seus servidores), eles podem optar por injetar código no seu site.
Individualmente, ferramentas de terceiros consolidadas são seguras e apresentam risco mínimo. Mas sites modernos têm dezenas de scripts de terceiros. Um relatório do Web Almanac constatou que a mediana de domínios de terceiros em um site é 23. E esses scripts de terceiros carregam mais scripts (scripts de quarta parte) para auxiliá-los 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 seus PDFs. Você nunca autorizou diretamente essa ferramenta de análise de documentos, mas ela é servida no seu site (e acessa informações sensíveis).
Você começa a perceber o problema: o seu site acaba com dezenas de scripts que podem injetar código sem que ninguém os monitore.
O que os atacantes fazem com os dados obtidos por e-skimming
Qual é o perigo, afinal? No cenário ideal para o atacante: eles criam um script que permite ver o que os usuários digitam no formulário de pagamento. Bingo. Agora eles veem os dados pessoais, o número do cartão, a data de validade e o código CVC.
Se conseguirem copiar e exfiltrar essas informações para o próprio servidor, o botim está garantido. Eles podem vender essas informações na dark web ou usar os dados do cartão para cometer fraudes.
Como lojistas online podem prevenir o e-skimming
1. Monitore scripts de terceiros: quais dados eles acessam e para onde os enviam?
O monitoramento de scripts em tempo real é essencial. Ferramentas que observam scripts de terceiros e seu comportamento emitem um alerta quando uma atividade suspeita é identificada. Por exemplo, se um script de analytics de repente começa a ler dados de formulários e enviá-los para um servidor na Rússia, você pode estar diante de um ataque client-side.
A plataforma cside monitora scripts de terceiros para verificar quais dados eles acessam e alerta imediatamente caso o acesso a dados mude.
2. Limite quais scripts rodam nas páginas de pagamento
Para os lojistas, o primeiro passo é saber quais scripts rodam nas páginas de pagamento. Uma medida preventiva é garantir que apenas os scripts necessários sejam executados ali. Tudo que não for estritamente necessário para pagamento ou prevenção de fraudes: elimine.
3. Use o cside para governança de scripts de terceiros
Muitos sites permitem por padrão que scripts de terceiros vão direto para o ambiente de produção. Equipes de marketing e desenvolvedores querem atualizações rápidas para melhorar a funcionalidade. Mesmo empresas que revisam cada script os aprovam uma vez e raramente os revisam novamente.
Pode parecer um trabalho manual enorme revisar cada script adicionado, mas uma ferramenta como o cside rastreia automaticamente cada novo script adicionado e fornece um resumo gerado por IA com uma pontuação de risco para que você possa aprovar rapidamente. Todos os scripts são mantidos em um "inventário ao vivo" que equipes de conformidade de privacidade ou segurança podem gerenciar com facilidade.
4. Implante controles de segurança do navegador: CSP e SRI
Os ataques de e-skimming acontecem no navegador, então podemos usar uma camada defensiva ali. CSP e SRI oferecem isso. É verdade que não resolvem tudo, mas criam mais visibilidade.
Um CSP restrito determina quais fontes podem carregar scripts e quais endpoints eles podem acessar. O conteúdo do script em si não é verificado, mas fluxos de dados indesejados são detectados e podem ser bloqueados. Comece com Content-Security-Policy-Report-Only para testar se tudo ainda funciona corretamente.
O SRI adiciona um hash aos arquivos: é assim que você verifica se um script foi modificado na origem ou durante a transferência. Isso torna muito mais difícil espalhar código malicioso por meio de uma atualização ou fornecedor comprometido. Funciona principalmente para scripts estáticos. Porém, scripts de terceiros com atualização automática quebram a verificação de hash.
Por que a segurança web tradicional não detecta o e-skimming
O malware não roda no servidor do lojista. Ele roda no navegador do cliente com os mesmos direitos e privilégios do código do próprio lojista.
O JavaScript é aceito e executado no DOM. As ferramentas tradicionais de segurança web frequentemente não têm visibilidade sobre isso. Mesmo ferramentas de defesa client-side como a Content Security Policy analisam apenas a origem de cada script. Se uma fonte confiável estiver servindo código malicioso, as políticas de segurança de conteúdo não detectarão nem bloquearão esse ataque.
