Resumo: como skimmers baseados em formulário roubam dados de cartão
- O seu WAF e o seu CSP vão dizer-lhe que o checkout está limpo enquanto os dados do cartão saem do navegador. Ambos os controlos vivem na camada de rede e o roubo acontece dentro do DOM, num script servido a partir de um domínio que a sua allowlist já confia.
- A Visa atribui 70% do roubo de cartões à camada cliente, e a British Airways perdeu cerca de 380.000 registos em 22 dias antes de pagar uma coima de 20 milhões de libras da ICO. A cside gera hash de cada payload de script em sessões de navegador reais e alerta no momento em que um hash muda.
- Se não consegue dizer se um script de um domínio de confiança foi modificado na última hora, está a uma troca de payload de se tornar o próximo caso de estudo.
O formjacking é um ataque web que injeta JavaScript malicioso numa página de pagamento ou de checkout para roubar dados de cartão à medida que um visitante os introduz. O script lê os valores dos campos do formulário em tempo real, envia-os para um servidor controlado pelo atacante e deixa a transação original concluir-se normalmente. O comprador recebe uma confirmação, o comerciante vê uma venda concluída e os dados do cartão já desapareceram. Como o roubo acontece dentro do navegador, permanece invisível aos controlos da camada de rede e de servidor em que a maioria dos comerciantes confia.
Como funciona o formjacking: passo a passo
O formjacking é um ataque na camada de execução. Não exige uma violação de rede nem o comprometimento de um servidor. Eis como decorre.
-
Um atacante injeta JavaScript malicioso numa página de pagamento ou de checkout. Isto é normalmente feito comprometendo um script de terceiros que o comerciante já carrega, como um gestor de tags, uma biblioteca de analytics ou um utilitário alojado numa CDN.
-
Quando um visitante chega ao formulário de pagamento, o script injetado começa a intercetar as pressões de tecla ou os valores dos campos no Document Object Model do navegador. Não precisa de esperar pelo envio do formulário.
-
À medida que o visitante introduz o número do cartão, a data de validade e o CVV, o script captura esses valores e exfiltra-os para um servidor controlado pelo atacante em tempo real. A transferência é normalmente codificada para evitar uma deteção óbvia na camada de rede.
-
O formulário original continua a funcionar. O pagamento é processado, o visitante recebe uma confirmação e nada no seu navegador ou nos registos do servidor do comerciante assinala algo invulgar.
É por isto que o formjacking é tão perigoso. Não há erro, nem transação falhada, nem anomalia na camada de rede ou de servidor. O ataque é invisível aos controlos que a maioria dos comerciantes tem implementados.
British Airways 2018: o que aconteceu
Em 2018, um ator de ameaça Magecart injetou um script de formjacking no site de reservas da British Airways e operou sem ser detetado durante 22 dias, comprometendo cerca de 380,000 registos de pagamento de clientes, incluindo números de cartão, datas de validade, CVVs e informações pessoais. Os sistemas internos não o detetaram durante essa janela porque não existia monitorização ao nível do payload.
O ataque modificou um script que já estava presente no site, por isso não surgiram novos URLs de script. Nenhuma regra de Content Security Policy foi acionada, porque o domínio que servia o script modificado já estava na lista de permissões.
A investigação do ICO resultou numa multa de £20 milhões. A conclusão sobre a causa raiz identificou a falha em detetar uma alteração de payload dentro de um script confiável como a falha técnica central.
A Visa relata que uma grande maioria do roubo de cartões de pagamento acontece agora na camada do cliente, no navegador, em vez de no servidor ou em trânsito:
| Onde os dados de cartão são roubados | Percentagem do roubo |
|---|---|
| Camada do cliente (navegador / DOM) | 70% |
| Camada de servidor / rede | 30% |
Fonte: Visa. O formjacking é o principal mecanismo por trás desses 70%.
Formjacking e Magecart: o que significa cada termo
Magecart é uma categoria de atores de ameaça, não uma técnica. O nome refere-se a um coletivo difuso de grupos criminosos que utilizam o formjacking como o seu principal método de ataque.
O formjacking é a técnica: injetar JavaScript para intercetar e exfiltrar dados de formulários. Os grupos Magecart estão entre os utilizadores mais prolíficos dessa técnica, mas não são os únicos.
Quando investigadores e jornalistas usam os termos de forma indistinta, estão normalmente a descrever um ataque de formjacking atribuído ao Magecart. A distinção importa para a deteção. Não está à procura da assinatura de um grupo específico; está à procura do comportamento de interceção de payload, seja quem for que esteja por trás.
Porque é que os WAFs e as CSPs não travam o formjacking
Uma firewall de aplicações web inspeciona o tráfego HTTP na camada de rede. Vê os pedidos e as respostas entre o navegador e o servidor, mas não tem visibilidade sobre que JavaScript é executado dentro do DOM depois de a página carregar. Um script de formjacking vive inteiramente no DOM. Não gera um pedido suspeito ao servidor do comerciante; envia os dados roubados diretamente para um endpoint controlado pelo atacante.
Uma Content Security Policy restringe quais os domínios autorizados a servir scripts, e é um controlo útil. Mas um ataque de formjacking normalmente modifica um script servido a partir de um domínio em que a CSP já confia. O domínio passa a verificação da lista de permissões e o próprio payload nunca é inspecionado. Esta é a mesma lacuna para a qual a Visa aponta quando atribui cerca de 70% do roubo de cartões à camada do cliente, onde os WAFs e os controlos do lado do servidor não têm linha de visão.
Como a monitorização de scripts da cside deteta o formjacking
A monitorização de scripts em sessões reais deteta o formjacking calculando o hash de cada payload de script à medida que este é executado dentro de um ambiente de navegador genuíno, alertando depois no momento em que qualquer hash muda. Isto apanha a injeção de payload dentro de scripts confiáveis que tanto uma lista de permissões de CSP como um WAF deixam passar.
A monitorização de scripts da cside é executada em sessões reais de navegador e combina mais de 100 sinais por sessão num veredito em tempo real.
Quando um payload de formjacking é injetado num script confiável, o hash desse script muda. A cside deteta a alteração em quase tempo real e dispara um alerta que inclui o identificador do script, o hash anterior, o novo hash e um carimbo temporal. O alerta chega antes de o script comprometido conseguir acumular um volume significativo de dados roubados.
O fingerprinting da cside mantém elevada precisão em sessões de navegação anónima, VPN e de limpeza de cookies, e a sua metodologia de monitorização é validada pela VikingCloud.
O requisito PCI DSS que visa especificamente o formjacking
Os Requisitos 6.4.3 e 11.6.1 do PCI DSS foram introduzidos especificamente para abordar o risco de formjacking e tornaram-se obrigatórios em 31 de março de 2025.
O Requisito 6.4.3 pede aos comerciantes que inventariem todos os scripts nas páginas de pagamento, documentem uma justificação de negócio para cada um, obtenham autorização explícita e verifiquem a integridade de forma contínua. Isto visa diretamente o cenário em que um script confiável é modificado sem o conhecimento do comerciante.
O Requisito 11.6.1 exige um mecanismo de alerta que dispara quando os cabeçalhos ou o conteúdo de uma página de pagamento mudam de forma não autorizada. A deteção em quase tempo real que a cside fornece cumpre e ultrapassa o que os QSAs procuram quando analisam as evidências do 11.6.1.
Verifique o risco de injeção nas suas páginas de pagamento e comece gratuitamente com o cside PCI Shield. Para saber como os termos se relacionam, veja formjacking vs Magecart vs digital skimming e, para saber como a monitorização contínua funciona na prática, veja as principais plataformas de monitorização de scripts de terceiros.
