Resumo: o que é formjacking
- JavaScript injetado em um formulário para roubar o que usuários digitam antes do submit. Campos de cartão, credenciais ou PII.
- Roda no navegador depois que a página é servida. Seu WAF e logs de origem não veem nada. O script comprometido fica dentro de um domínio confiável permitido.
- Caminho de conformidade: inventário de scripts 6.4.3 e detecção de adulteração 11.6.1. Caminho técnico: monitoramento em sessão.
Como funciona o formjacking
Um ataque de formjacking segue quatro passos.
O diagrama segue um checkout (shop.example[.]com/checkout) ao longo de cinco etapas, e mostra por que uma vista ao nível da rede fica cega enquanto uma vista ao nível do browser o deteta:
| Etapa | O que acontece no browser | O que o servidor / a CSP vê |
|---|---|---|
| 1. Página de checkout | O comprador digita o número de cartão + CVV no formulário real | Carregamento de página normal |
| 2. Script de fornecedor adulterado | widget.js (modified) carrega como qualquer outra tag de terceiros | Um URL de script permitido e já de confiança |
| 3. Skimmer do formulário | O listener injetado liga-se a cada campo de entrada e lê as teclas em tempo real | Nada, nenhum pedido ao servidor |
| 4. Endpoint de exfiltração | Cópia codificada enviada para cdn-metrics[.]example via POST /collect?d=eyJjYyI6…, disfarçada de baliza de análise | Parece tráfego de análise comum |
| 5. Atacante | Os cartões roubados são revendidos ou usados para fraude com cartões; o pagamento real conclui-se na mesma | Sem anomalia, a transação tem sucesso |
A camada de rede fica cega porque o pedido de exfiltração sai do browser diretamente para o domínio do atacante. A cside observa a camada do browser, por isso o listener injetado e a baliza de saída são detetados onde realmente são executados.
1. Colocar código na página. O atacante coloca JavaScript na página alvo, quase sempre sem o conhecimento do proprietário do site. A rota mais comum é comprometer um script de terceiros, uma tag de análise, um widget de chat, uma ferramenta de testes A/B ou uma biblioteca de pagamentos, para que o skimmer chegue embalado dentro de código em que o site já confia e que carrega em cada checkout.
2. Ligar-se aos campos do formulário. Assim que o script é carregado, liga listeners de eventos ao formulário de pagamento ou início de sessão. Um listener no evento input é acionado em cada tecla pressionada; um no evento submit é acionado quando o utilizador clica em pagar. O script também pode ler diretamente os valores do DOM depois de os campos estarem preenchidos.
3. Copiar os dados. O listener captura os valores dos campos, número de cartão, validade, CVV, morada de faturação, exatamente como o utilizador os introduziu. O próprio formulário não é modificado. A transação do utilizador continua a ser processada pelo processador de pagamentos legítimo.
4. Exfiltrar. Os dados roubados são codificados e enviados para um domínio controlado pelo atacante, muitas vezes disfarçados como um ping de análise ou um pedido de imagem para se misturarem com o tráfego de saída normal da página. A maioria dos cabeçalhos Content Security Policy não bloqueia isto porque o atacante utiliza um domínio que a política já permite ou explora uma lacuna existente.
Como os atacantes introduzem código de formjacking no seu site
O formjacking não requer uma violação direta dos seus servidores. As três rotas de entrega mais comuns:
Comprometimento de scripts de terceiros. A maioria das páginas de pagamento e e-commerce carrega entre 20 e 60 scripts de terceiros, plataformas de análise, ferramentas de chat, gestores de tags, bibliotecas de pagamentos, widgets de fornecedores de marketing. Qualquer um desses fornecedores é uma superfície de ataque. Se o atacante comprometer a CDN ou a infraestrutura do fornecedor, todos os sites que carregam esse script recebem o skimmer. A violação da British Airways em 2018 pôs em risco os dados pessoais de 429.612 clientes após os atacantes terem modificado o JavaScript no fluxo de pagamento da companhia aérea. Os investigadores ligaram o ataque a atores de ameaça da Magecart que utilizaram um script de fornecedor externo comprometido, e não uma violação direta dos próprios servidores da British Airways. (Wikipedia: Violação de dados da British Airways)
Domínios expirados ou sequestrados. Os sites carregam por vezes scripts de domínios de terceiros que entretanto expiraram ou mudaram de proprietário. Um atacante que registe esse domínio pode então servir qualquer JavaScript que queira a todos os sites que ainda carregam a antiga tag de script. Como o URL não mudou e o domínio servia anteriormente código legítimo, nenhuma verificação automática o assinala imediatamente.
Injeção direta de código. Se o atacante explorar uma vulnerabilidade no CMS, no painel de administração ou num plugin do site, pode injetar o script de formjacking diretamente nos próprios ficheiros do site. Esta rota requer mais acesso, mas não deixa nenhuma dependência externa para rastrear.
O que o formjacking tem como alvo
Os atacantes priorizam páginas que recolhem dados de alto valor com o mínimo de fricção:
| Tipo de página | Dados geralmente capturados |
|---|---|
| Checkout de e-commerce | Número de cartão, validade, CVV, morada de faturação |
| Registo de conta | E-mail, palavra-passe, nome, morada postal |
| Páginas de início de sessão | Nome de utilizador e palavra-passe |
| Formulários de saúde | Número de seguro, data de nascimento, informações de saúde |
| Pedidos de conta financeira | NIF, rendimentos, dados bancários |
As páginas de checkout são o alvo principal porque os dados de cartão têm um mercado de revenda imediato. As credenciais de início de sessão são a segunda prioridade porque permitem a tomada de controlo de contas em plataformas com métodos de pagamento guardados.
Por que as ferramentas de segurança tradicionais falham com o formjacking
Os firewalls de aplicações web protegem o tráfego que chega ao seu servidor. Os dados do formjacking saem do navegador diretamente para um domínio do atacante, o WAF nunca os vê.
Os scanners do lado do servidor inspecionam o código em repouso na sua origem. Um script de terceiros comprometido carrega da CDN de um fornecedor em tempo de execução, pelo que nunca está no seu servidor para ser analisado.
As revisões manuais periódicas verificam os scripts listados no seu gestor de tags ou repositório de código. Um skimmer injetado num script de terceiros entre ciclos de revisão é invisível até alguém executar a próxima auditoria, muitas vezes semanas depois.
A Subresource Integrity (SRI) protege os scripts para os quais calcula um hash no momento da implementação. Não consegue proteger scripts carregados de CDNs controladas por fornecedores onde o atacante tem acesso de escrita, nem scripts gerados dinamicamente por pedido.
Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 existem porque o setor reconheceu esta lacuna. O inventário de scripts e a monitorização contínua de adulterações nas páginas de pagamento tornaram-se obrigatórios a 1 de abril de 2025. (PCI Security Standards Council)
Os skimmers também iludem ativamente os scanners. A maioria verifica navigator.webdriver, que retorna true em navegadores headless automatizados, e serve código limpo às ferramentas de segurança enquanto executa o skimmer completo para utilizadores reais.
Como detetar o formjacking
Detetar o formjacking requer visibilidade sobre o que o JavaScript faz em tempo de execução nos navegadores de visitantes reais. Os sinais específicos a monitorizar:
- Scripts novos ou modificados em páginas sensíveis. Um script que não estava presente no dia anterior, ou cujo conteúdo mudou fora de uma janela de implementação programada, é o primeiro indicador.
- Listeners de eventos inesperados em campos de formulário. O código legítimo liga listeners
submitpara processar formulários. Um listener em eventosinput,keydownoukeyupem campos de pagamento ou credenciais, adicionado por um script de terceiros, é uma assinatura de formjacking. - Dados de saída para domínios não listados. Qualquer pedido de rede de uma página de pagamento para um domínio que não conste da sua lista permitida aprovada requer investigação imediata.
- Payloads codificadas em pedidos de saída. Os formjackers codificam os dados roubados, frequentemente em base64, antes de os enviar. Um beacon com um parâmetro codificado invulgarmente longo que não corresponde a nenhum evento de análise conhecido é um sinal de alerta.
A limitação fundamental é que apenas a monitorização dentro do navegador consegue ver estes sinais em condições reais. Os scanners que operam do exterior falham com o formjacking que se oculta dos utilizadores reais.
Como prevenir o formjacking
Nenhum controlo único elimina todas as rotas de formjacking. Combinar vários controlos reduz significativamente a superfície de ataque:
-
Inventariar todos os scripts em páginas sensíveis. Conhecer cada script próprio e de terceiros que carrega nas páginas de pagamento e início de sessão, quem o autorizou e por que está lá. Scripts não reconhecidos não devem carregar.
-
Monitorizar alterações continuamente. Um script que muda entre ciclos de auditoria é uma violação não detetada. A monitorização contínua de adulterações, obrigatória ao abrigo do requisito 11.6.1 do PCI DSS 4.0.1, deteta alterações em minutos em vez de semanas.
-
Aplicar SRI onde for prático. Para scripts que controla completamente e versiona você mesmo, os hashes SRI verificam que o script não foi alterado desde a implementação. A SRI não funciona para scripts de terceiros frequentemente atualizados ou gerados dinamicamente por pedido.
-
Configurar a Content Security Policy de forma restritiva. Uma CSP rigorosa limita os domínios para os quais os scripts podem enviar dados, reduzindo as opções de exfiltração de um skimmer. Na prática, as páginas de pagamento frequentemente precisam de permitir muitos domínios para análises legítimas e funcionalidades de pagamento, tornando um bloqueio completo difícil.
-
Implementar monitorização client-side de visitantes reais. A defesa mais direta é a monitorização que observa o que cada script faz em navegadores reais, não um scanner que executa pedidos sintéticos do exterior. Esta é a abordagem da cside.
Como a cside deteta o formjacking em navegadores reais
A cside é implementada como um único snippet de JavaScript próprio que monitoriza o comportamento dos scripts nos navegadores de visitantes reais, não um crawler ou scanner que opera do exterior.
Para o formjacking, a cside deteta:
- Listeners de eventos ligados a campos de formulário por scripts de terceiros, com especial atenção aos listeners que são acionados em teclas pressionadas em vez de no envio do formulário
- Pedidos de dados de saída para domínios que não constam da lista permitida aprovada do site
- Novos scripts que aparecem em páginas de pagamento ou início de sessão fora de uma janela de implementação
- Alterações em scripts existentes, incluindo modificações em tempo de execução na saída carregada de uma tag de fornecedor
Como a cside opera na camada do navegador ao lado do ataque, deteta o skimmer no momento em que é acionado, antes de os dados terem sido já exfiltrados. Para as organizações sujeitas ao PCI DSS 4.0.1, o PCI Shield mapeia esta monitorização para os requisitos 6.4.3 (inventário e autorização de scripts) e 11.6.1 (deteção de adulterações), gerando relatórios prontos para o QSA de forma contínua.
Para contexto sobre como o formjacking se relaciona com o ecossistema mais amplo do skimming digital e os grupos de ameaça Magecart, consulte o guia complementar: Formjacking vs Magecart vs skimming digital.
Agende uma demo para ver o que a cside encontra nas suas páginas de pagamento, ou saiba mais sobre prevenção de e-skimming.
