TL;DR: guia de skimming no navegador
- Servidores sólidos, controlos de PCI e uma WAF parecem suficientes, mas algumas linhas de JavaScript malicioso no navegador conseguem recolher dados de cartão e PII durante semanas, enquanto os seus pagamentos legítimos continuam a ser concluídos com sucesso e os dashboards continuam verdes.
- A tokenização e os processadores de pagamento também não o protegem: se os campos do seu checkout estiverem alojados no seu próprio domínio, os scripts de terceiros continuam a poder ler o que os utilizadores digitam, e o cside inspeciona cada script no navegador para sinalizar transferências de dados para o exterior.
- O e-mail de apoio ao cliente sobre um cartão comprometido costuma chegar antes de os seus dashboards sequer piscarem, por isso decida já se a monitorização contínua do lado do cliente deve fazer parte do seu stack, em vez de um processo de revisão trimestral.
Sem tempo? Veja o bloqueio no navegador de Magecart e skimmers da cside. Cobre tudo o que se segue numa única implementação.
TL;DR: Ataques Magecart
- O que é um ataque Magecart: um ataque Magecart é um ataque de web skimming baseado no navegador, em que JavaScript malicioso é injetado num site com o objetivo de roubar dados de cartão de pagamento ou dados sensíveis introduzidos em formulários, diretamente do navegador do utilizador, durante o checkout ou o login.
- Por que razão os ataques Magecart são difíceis de detetar: o Magecart opera inteiramente no navegador, pelo que defesas tradicionais como WAFs, SIEMs e a monitorização de transações não detetam nada de invulgar enquanto os pagamentos legítimos continuam a ser processados com sucesso.
- Como prevenir ataques Magecart: uma prevenção eficaz exige minimizar os scripts nas páginas de checkout, governar e monitorizar o JavaScript de terceiros, aplicar controlos de navegador como CSP e SRI, e implementar uma ferramenta de monitorização contínua do lado do cliente como o cside.
"Fui recentemente notificado de uma violação de dados na sua loja e o meu cartão de crédito foi utilizado indevidamente."
Isto é um pesadelo para o apoio ao cliente. As suas equipas de fraude e financeira também estão a receber alertas dos emissores de cartões e questões dos fornecedores de pagamentos.
O Magecart não falsifica páginas de login ou de pagamento. Abusa das próprias páginas de login e checkout em que os seus clientes já confiam.
O seu login e checkout tornam-se o elo mais fraco dos seus controlos de segurança. Mesmo servidores sólidos, uma WAF e controlos de PCI não impedem que algumas linhas de JavaScript malicioso no navegador recolham dados de cartão e PII durante semanas antes de alguém dar por isso.
Este guia mostra o que é o Magecart, como funciona, por que é difícil de detetar e quais as ferramentas para prevenção de Magecart.
O que é um ataque Magecart?
Um ataque Magecart é um ataque de web skimming baseado no navegador. JavaScript malicioso é injetado num site de e-commerce com um único objetivo: roubar dados de cartão de pagamento.
É algo que não deseja nem para si nem para os seus clientes. É um pesadelo para lojas online porque abusa da confiança dos seus clientes. Causa danos significativos ao negócio online: perdas financeiras, chargebacks, multas regulatórias e danos sérios à reputação.
A sua WAF e a stack de segurança do lado do servidor não vão detetar nada disto. O ataque decorre inteiramente no navegador do utilizador, num ambiente de código que a monitorização do seu backend nunca alcança. Mesmo outros controlos relacionados com o PCI DSS, como a encriptação ou a tokenização, não valem de nada se o atacante roubar os dados do cartão antes de essas defesas entrarem sequer em ação. As transações do seu lado continuam a ser processadas como se nada estivesse errado. Da sua perspetiva, parece tudo normal. Mas, entretanto, os dados são silenciosamente exfiltrados do navegador do seu cliente para os servidores do atacante.
O Magecart é um tipo de web skimming
O Magecart é uma forma de web skimming (ou e-skimming). O web skimming é a versão online da clonagem de cartões de crédito em multibancos: as teclas digitadas ou os dados introduzidos são copiados por dispositivos ocultos e depois usados para gastar dinheiro noutro local. Quando os atacantes adicionam o seu JavaScript malicioso a uma loja online, isso abre-lhes muitas oportunidades. Conseguem ver o que um utilizador digita em formulários de pagamento ou login e exfiltram secretamente esses dados para os seus próprios sistemas.
Como evoluiu o termo "Magecart"
Por volta de 2015-2016, investigadores de segurança começaram a reportar que lojas online baseadas em Magento estavam a ser alvo de ataques de clonagem de cartões online. Tipicamente, JavaScript era injetado nas páginas de checkout para roubar e exfiltrar dados de pagamento e PII. Daí o nome: "Magecart" — "Mage" de Magento e "cart", abreviatura de shopping cart (carrinho de compras).
Com o tempo, os ataques Magecart espalharam-se para outras plataformas e configurações de e-commerce personalizadas. Qualquer plataforma com JavaScript do lado do cliente e scripts de terceiros era vulnerável, não apenas o Magento.
Da clonagem de cartões no Magento aos ataques em estilo Magecart em todo o lado
O Magecart evoluiu para um estilo de ataque: um rótulo para digital skimming, formjacking, e-skimming, clonagem de cartões online, e tornou-se uma ameaça importante para as plataformas de retalho online.
O Magecart é menos uma alcunha para um grupo específico e mais um rótulo abrangente para um ecossistema de grupos e técnicas de digital skimming. De um modo geral, usam o mesmo vetor de ataque, mas recorrem a infraestruturas e ferramentas diferentes.
Como funcionam os ataques Magecart
A ideia parece simples: copiar dados de formulário e exfiltrá-los para um endpoint comprometido. Quão difícil pode isso ser? Na realidade, estes ataques são mais subtis e sofisticados. Em cada momento, a loja online precisa de se comportar como esperado: sem erros, sem timeouts.
Para que o digital skimming seja bem-sucedido, nem os seus sistemas de monitorização nem os seus clientes podem notar nada de invulgar.
Eis como se desenrola um ataque Magecart típico no navegador
1. Injeção de JavaScript malicioso no site
Primeiro, o atacante precisa de uma forma de executar o seu próprio JavaScript no navegador do utilizador, porque é aí que o ataque acontece. Procura vulnerabilidades como plugins ou componentes de CMS desatualizados ou mal configurados, ou scripts de terceiros negligenciados, como um plugin, ficheiros de CDN, tag manager, entre outros.
Este ponto fraco torna-se o vetor de ataque: o atacante acrescenta algumas linhas do seu JavaScript malicioso a um ficheiro de produção existente ou a um script de terceiros. A alteração é mínima, muitas vezes misturada com código legítimo, pelo que nada se destaca durante uma revisão de segurança.
2. Leitura dos dados de pagamento e de formulário
Feito isto, o JavaScript malicioso acede ao DOM e lê os dados que o utilizador introduziu no formulário. O acesso e a alteração do DOM pelo JavaScript são comportamentos normais no desenvolvimento web moderno. É assim que o JavaScript torna as páginas dinâmicas sem recarregar todo o documento HTML. Muitas frameworks, como React ou Svelte, dependem do facto de o JavaScript poder manipular o DOM.
O digital skimmer concentra-se agora em campos específicos do formulário de pagamento ou login: número do cartão, data de validade, CVV, nome, morada, entre outros. Copia estes valores sem alterar o formulário nem o fluxo do utilizador de forma visível.
3. Exfiltração dos dados para o servidor do atacante
Depois de os dados serem capturados, o passo seguinte é transferi-los sem serem detetados para um servidor controlado pelo atacante. Na maioria das vezes, o gatilho para a exfiltração é o clique do utilizador no botão "pagar"/"submeter". Nesse momento, o script monta o payload (em bruto ou codificado) com os dados do cartão, PII e, frequentemente, detalhes de contexto como timestamps ou URLs.
As técnicas de exfiltração típicas incluem fetch, XMLHttpRequest (para código mais antigo), pedidos ocultos de imagens e navigator.sendBeacon(). O TLS/HTTPS não impede a exfiltração porque esta se apresenta como um pedido https legítimo, com um payload muito pequeno. Os atacantes utilizam frequentemente domínios muito semelhantes aos hostnames legítimos usados por lojas online, CDNs ou ferramentas de analítica, para não levantarem suspeitas. Se o pedido de exfiltração falhar, o código simplesmente apanha o erro e não é executado. Mas a transação legítima segue em frente.
4. Manter a loja em funcionamento e o processamento de encomendas a decorrer
Para que o ataque Magecart seja eficaz, as transações têm de continuar a fluir. O skimmer exfiltra uma cópia dos dados, mas o formulário de pagamento também é submetido ao seu backend e ao gateway de pagamento. As encomendas são criadas, os pagamentos são autorizados e os seus sistemas de processamento de encomendas entram em ação.
Como os atacantes obtêm acesso aos scripts web para ataques Magecart
Os atacantes andam à procura de pontos fracos na sua stack web: locais onde os scripts podem ser editados e código de skimming pode infiltrar-se. Para defender o seu site e construir um modelo de ameaça eficaz, precisa de se concentrar em alguns pontos de entrada comuns dos ataques Magecart.
1. Magecart através de plugins, CMS ou código da plataforma de e-commerce
O seu próprio CMS ou plataforma de e-commerce é uma superfície de ataque direta. Plataformas como Magento, WooCommerce, apps do Shopify e código de checkout personalizado precisam de escrutínio regular. Os pontos fracos típicos são plugins e extensões desatualizados, ou edições inseguras em templates ou ficheiros JavaScript. As contas de administrador precisam de proteção extra: se um atacante conseguir iniciar sessão como administrador, alterar scripts torna-se fácil.
Se a sua loja online estiver a executar um plugin de pagamento ou de rastreio desatualizado no Magento ou no WooCommerce, o digital skimming está apenas a um passo de distância. Se os atacantes conseguirem modificar os ficheiros do plugin ou abusar de uma conta de administrador, só precisam de editar um único ficheiro JavaScript na página de checkout para adicionar o seu skimmer.
2. Magecart através da cadeia de fornecimento de código de terceiros
Isto inclui qualquer entrada via <script src> ou um tag manager: bibliotecas de CDN, testes A/B ou analítica para a sua equipa de marketing, widgets de chat/apoio ao cliente, entre outros. Estes scripts são geridos e alojados por fornecedores externos ou injetados através de tag managers que podem executar código na maioria das páginas. Basta um único script de terceiros comprometido ou uma conta de tag manager comprometida para espalhar código de skimmer a todos os sites e páginas onde esse código é utilizado.
Por vezes, uma conta do Google Tag Manager (GTM) ou um widget de chat externo tem código que carrega em todo o site (incluindo as páginas de checkout), mesmo que não sirva qualquer função nessas páginas. Se o GTM for comprometido e for adicionada uma tag extra com código JavaScript de skimmer, todos os formulários de checkout de todos os sites que usam esse contentor passam a executar código Magecart.
Por que razão os ataques Magecart são difíceis de detetar
Agora que já vimos como funciona um ataque Magecart no navegador, é justo perguntar: por que razão as defesas tradicionais não o detetam? Temos regras de WAF, dashboards de SIEM e controlos de PCI. Ainda assim, estas camadas de segurança continuam a ter um ponto cego para ataques do lado do cliente baseados no navegador, como o Magecart.
1. WAF, SIEM e dados de transações não detetam ataques Magecart
A maioria das ferramentas de segurança web foi concebida para proteger a atividade do lado do servidor ou monitorizar a infraestrutura da empresa, não o navegador dos utilizadores. Uma WAF inspeciona o tráfego para as suas aplicações, mas não vê o que o navegador envia diretamente para outros domínios. Um SIEM mostra registos de servidor e de infraestrutura, mas não regista chamadas de saída adicionais do navegador para endpoints maliciosos.
Analisar dados de transações à procura de fraude não vai revelar indícios de um ataque Magecart, porque o fluxo de compra legítimo continua a concluir-se normalmente. O skimmer copia os dados do cartão no navegador enquanto o backend vê uma transação limpa e autorizada, sem qualquer anomalia.
Atacantes experientes conseguem intercetar valores sensíveis ao nível do DOM antes de estes serem sequer enviados para os seus servidores, silenciando eficazmente os seus sistemas de alerta.
2. A falta de visibilidade sobre scripts de terceiros aumenta o risco de Magecart
Ter visibilidade total sobre os scripts de terceiros é um desafio enorme. Que scripts estão em execução? Têm permissão para ser executados num formulário de checkout ou numa página de login? Quem acompanha o seu comportamento e as suas alterações ao longo do tempo? São perguntas muito básicas com que muitas organizações têm dificuldade quando ninguém detém verdadeiramente a propriedade da cadeia de fornecimento do lado do cliente.
Os programadores web têm um controlo limitado sobre estes scripts, porque são geridos e alojados por fornecedores externos. Quando a propriedade muda ou há despedimentos, os scripts de terceiros ou as bibliotecas JavaScript podem deixar de ser atualizados, e uma vulnerabilidade em qualquer um desses scripts de terceiros pode tornar-se um risco de segurança.
É exatamente este o ponto de entrada explorado pelos ataques Magecart. Comprometer um único script ou biblioteca de terceiros amplamente utilizado pode transformá-lo num ataque à cadeia de fornecimento em larga escala, afetando todos os sites que o usam.
3. Um problema do lado do cliente exige uma defesa do lado do cliente
Este é o problema central do Magecart: a maioria das empresas não tem visibilidade real sobre o que acontece no navegador. Os dashboards de segurança do lado do servidor não mostram para que domínios o navegador está a enviar pedidos durante o checkout, mesmo quando se trata de chamadas cross-origin (CORS).
Não alertam quando surge um novo domínio de saída num formulário de pagamento. E não enviam um aviso sobre uma violação de Content Security Policy (connect-src) quando um script está a tentar exfiltrar dados para um endpoint inesperado.
4. A fraude só é descoberta mais tarde, muito mais tarde
Guias relacionados
Aprofunde-se neste cluster:
Um dos aspetos mais prejudiciais de um ataque Magecart é que raramente é detetado pela própria organização que foi violada. Na maioria dos casos, os primeiros sinais de problema vêm de bancos, emissores de cartões ou clientes. Quando estes relatos externos surgem, o skimmer já recolheu um volume significativo de dados de titulares de cartão.
Como prevenir ataques Magecart
Os princípios centrais da prevenção de Magecart são diretos: mantenha o seu fluxo de checkout o mais limpo e minimalista possível, mantenha o controlo dos scripts que aí são executados e adicione controlos do lado do navegador com monitorização contínua 24 horas por dia, 7 dias por semana. Estes passos vão ajudar a reduzir a sua exposição ao Magecart.
1. Execute apenas os scripts necessários no login e no checkout
No login e no checkout, cada script adicional acrescenta risco. Estas páginas devem carregar apenas o essencial de UX e o estritamente necessário para a autenticação e o pagamento. Sem hesitação, remova marketing, analítica, widgets de chat e semelhantes do login e do checkout.
De preferência, isole o checkout e utilize um template minimalista ou até mesmo um subdomínio separado com apenas os inputs de terceiros necessários. Isto limita a sua superfície de ataque e as oportunidades para o código Magecart esconder o seu rasto. Também torna a limpeza muito mais fácil se algo correr mal.
2. Use o cside para governação de scripts de terceiros
Crie um inventário de scripts para ter uma visão clara de que scripts são executados onde e o que fazem, de facto. As páginas sensíveis, incluindo login e checkout, só devem servir scripts de terceiros que tenham sido aprovados com uma justificação.
Por fim, defina um processo de gestão de mudanças para especificar quem tem permissão para modificar scripts e contentores de tag manager. Pode também exigir pré-visualizações e aprovação antes de as alterações entrarem em produção. Em paralelo, aplique uma governação rigorosa de fornecedores e integre a segurança de scripts e o tratamento de incidentes nos contratos e no onboarding com fornecedores externos.
Uma ferramenta de governação de scripts de terceiros pode automatizar estes elementos instantaneamente com um dashboard que associa cada script a um fornecedor e gera automaticamente descrições do que cada script está a fazer.
3. Use controlos de navegador: CSP e SRI
Uma Content Security Policy (CSP) ajuda a definir de onde os scripts têm permissão para carregar (script-src) e para onde o navegador tem permissão para enviar dados (connect-src).
O script-src deve estar restrito a domínios de confiança e o connect-src deve permitir apenas os endpoints necessários para o checkout, em vez de permitir qualquer destino.
Ativar uma CSP também ajuda a reportar violações de política, especialmente no login e no checkout. Tentativas inesperadas de injeção de scripts e de exfiltração serão reveladas. Para bibliotecas de terceiros estáticas, utilize Subresource Integrity (SRI) para reforçar a integridade, mas trate-a como uma camada da sua defesa, não como a solução milagrosa.
4. Use o cside para monitorização de Magecart
Com o Magecart, precisa de olhos dentro do navegador. A monitorização contínua e automatizada do lado do cliente, 24 horas por dia, 7 dias por semana, revela que scripts estão em execução e comportamentos suspeitos que sinalizam atividade Magecart. Uma ferramenta de prevenção de Magecart mapeia todos os scripts do seu site e utiliza um motor assistido por IA para detetar sinais de alerta a partir de uma variedade de pontos de dados.
O cside ajuda os comerciantes a identificar e parar:
- Ataques à cadeia de fornecimento de JavaScript de terceiros
- Scripts de terceiros maliciosos ou adulterados
- Scripts mal configurados que vazam dados sensíveis
- Magecart, e-skimming, formjacking e skimmers relacionados
O cside está validado para os requisitos do lado do cliente do PCI DSS 4.0.1 e é utilizado por equipas de conformidade para prevenir violações do RGPD, do CCPA e de outras normas de privacidade causadas por scripts de terceiros de risco.
Autoavaliação rápida de preparação contra o Magecart
Está preparado para se defender de ataques em estilo Magecart? Sim/Não
- As nossas páginas de checkout e login carregam apenas scripts cujo propósito e comportamento esperado conhecemos
- Temos uma lista atualizada de todos os scripts, próprios e de terceiros, que são executados na nossa página de checkout
- O marketing, a analítica, os testes A/B e os widgets de chat são monitorizados para garantir que não recolhem mais dados do que o necessário
- As alterações a scripts "de confiança", como contentores de tag manager…
- Estamos a verificar a integridade dos scripts através de uma ferramenta de segurança do lado do cliente ou de outro mecanismo (como o Sub Resource Integrity)
- Temos monitorização do lado do cliente que mostra para onde estão a ser enviados os dados recolhidos pelos scripts de terceiros
- Temos um mecanismo implementado para bloquear scripts identificados publicamente como comprometidos
Os maiores ataques Magecart da história recente
O nosso relatório de ameaças do lado do cliente de 2025 identificou mais de 72 000 sites afetados por ataques do lado do cliente. Esses ataques seguem o mesmo padrão dos maiores ataques Magecart da história recente: algumas linhas de JavaScript malicioso comprometem milhões de utilizadores antes de alguém dar por isso. Segue-se um resumo rápido dos casos mais notáveis.
- Ticketmaster (2018) - script de chatbot comprometido Os atacantes injetaram código de skimming num chatbot de terceiros alojado pela Inbenta Technologies. Cada carregamento de página executava o script malicioso, expondo dados de pagamento e pessoais de cerca de 9,4 milhões de clientes ao longo de quatro meses. O incidente levou a multas regulatórias e a acordos em ações coletivas.
- British Airways (2018) - 22 linhas de JavaScript malicioso Os atacantes obtiveram acesso através de credenciais de terceiros comprometidas e inseriram apenas 22 linhas de código skimmer numa biblioteca usada na página de pagamento da BA. Os dados foram exfiltrados para um domínio muito semelhante ao legítimo ("baways.com"), afetando cerca de 400 000 clientes. A BA enfrentou dezenas de milhões em multas de RGPD e anos de litígio.
- Newegg (2019) - script injetado na página de checkout Os atacantes obtiveram acesso de escrita ao servidor de pagamentos da Newegg e adicionaram um pequeno skimmer ao botão de checkout. Quando os clientes submetiam o pagamento, os dados do cartão eram enviados para um domínio falso de analítica ("neweggstats.com"), comprometendo números de cartão, CVVs e PII durante mais de um mês antes da deteção.
O que é o Magecart
O Magecart é uma família de ataques de skimming baseados no navegador, em que JavaScript malicioso é injetado num site legítimo (normalmente a página de checkout ou login) e captura dados de cartões de pagamento, credenciais ou dados pessoais à medida que o utilizador os digita. O atacante raramente toca no servidor. O script malicioso é executado inteiramente no navegador do visitante, o que significa que as defesas tradicionais do lado do servidor (WAFs, agentes de endpoint, SIEMs) não veem o roubo a acontecer. O banco emissor do cartão, semanas ou meses depois, é muitas vezes a primeira parte a notar que algo está errado, quando surge fraude duplicada em titulares de cartão que partilhavam um comerciante em comum.
O termo Magecart referia-se originalmente a grupos criminosos específicos que visavam lojas Magento em 2015-2016, mas em 2026 designa toda a classe de ataques de skimming do lado do cliente, independentemente da plataforma (WordPress, Shopify, stacks personalizados, todos afetados). O vetor de injeção varia: scripts de terceiros comprometidos, ferramentas de desenvolvimento sequestradas, credenciais de CI/CD expostas ou o comprometimento direto do próprio pipeline de build de JavaScript do comerciante.
O cside inspeciona em tempo real todos os scripts em execução no checkout do comerciante, pelo que as injeções Magecart são detetadas no momento em que surgem, em vez de semanas depois, quando as redes de cartões correlacionam a fraude.
Camadas de mitigação e proteção contra o Magecart que se mantêm eficazes em 2026
A mitigação e a proteção contra o Magecart em 2026 exigem camadas, porque nenhum controlo isolado apanha todos os vetores de injeção. A stack que efetivamente aguenta tem quatro peças estruturais: uma Content Security Policy rigorosa na página de checkout (bloquear fontes de scripts não confiáveis, permitir apenas o que o checkout precisa), Subresource Integrity em todos os scripts de terceiros (falhar o carregamento se o hash do script mudar), um inventário formal de scripts de terceiros que um QSA possa auditar face ao requisito 6.4.3 do PCI DSS 4.0.1, e monitorização contínua do lado do navegador que apanha skimmers independentemente da forma como a injeção ocorreu.
A CSP e o SRI são necessários mas não suficientes. O SRI só protege os scripts que se conseguem fixar a um hash fixo, mas a analítica, os tag managers e outros códigos de terceiros mudam com demasiada frequência para serem fixados, pelo que os operadores de Magecart mais sofisticados visam precisamente esses scripts não fixados, ou subvertem um script de confiança que carrega mais código em tempo de execução sem sair da lista de permissões da sua CSP. É aí que a monitorização contínua se torna estrutural.
O cside executa a camada de monitorização contínua: todos os scripts em execução no checkout são inventariados, verificados quanto à integridade e observados quanto a comportamento de exfiltração. Quando um script anteriormente de confiança começa a fazer pedidos de saída para um domínio desconhecido, o cside sinaliza-o e pode bloquear o payload antes de os dados do cliente saírem do navegador. Para a análise completa do ataque e orientações sobre a configuração de CSP, o resto deste manual cobre os passos operacionais em profundidade.
FAQ
Como sei se o meu site tem uma infeção de Magecart ou e-skimming?
Os ataques Magecart são difíceis de detetar porque o checkout continua a funcionar normalmente e as ferramentas do lado do servidor não detetam nada de invulgar. O único método fiável é a monitorização do lado do cliente com uma ferramenta como o cside, que inspeciona os scripts em execução no navegador e sinaliza alterações suspeitas de código ou transferências de dados para o exterior.
Os ataques Magecart podem acontecer mesmo que eu utilize um processador de pagamentos como o Stripe ou o PayPal?
Sim. Se os campos do seu checkout estiverem alojados no seu próprio site (mesmo utilizando um processador de pagamentos de terceiros), os scripts de terceiros presentes na sua página podem continuar a aceder ao que os utilizadores digitam nesses campos. Se o seu site redirecionar totalmente os clientes para o domínio de um fornecedor de pagamentos (por exemplo, checkout.stripe.com), o Magecart não consegue recolher dados de cartão nesse ponto. No entanto, outras informações sensíveis do seu site, como credenciais de login ou dados de KYC, ou detalhes de conta, podem continuar a ser recolhidas se existirem scripts maliciosos.
Um ataque Magecart pode acontecer se eu tokenizar ou encriptar os dados do cartão de crédito?
Sim. A tokenização e a encriptação só ocorrem depois de o cliente submeter o pagamento, mas o Magecart rouba os dados enquanto o utilizador está a digitá-los. Mesmo os fluxos totalmente tokenizados ou encriptados continuam vulneráveis ao skimming se houver scripts maliciosos em execução na página.
