Comment détecter les skimmers Magecart et formjacking

Magecart est le nom d'une famille d'attaques qui volent les données de cartes de paiement et de formulaires en injectant du JavaScript malveillant dans une page de paiement. La technique s'appelle le formjacking : un skimmer lit ce qu'un client saisit dans le formulaire de paiement et en envoie discrètement une copie à l'attaquant, pendant que la transaction légitime, elle, aboutit normalement. Comme le skimmer s'exécute dans le navigateur, dans du code qui se charge de la même manière que vos vrais scripts, vos serveurs et votre pare-feu applicatif web ne le voient jamais. Pour l'attraper, il faut se placer côté client : inventorier les scripts qui s'exécutent réellement, alerter quand cet ensemble change, et limiter ce qu'une injection peut faire avec une politique de sécurité du contenu (CSP) stricte.

C'est le pendant « menace » de comment les attaquants abusent de Google Tag Manager, qui couvre un vecteur de distribution courant, et de CSP pour PCI DSS v4, qui couvre les exigences de conformité bâties autour de ce risque précis.

Ce que sont Magecart et le formjacking

Un skimmer de formjacking est un petit bout de JavaScript qui s'attache au formulaire de paiement et capture les valeurs des champs : numéro de carte, expiration, CVV, nom, adresse. Il attend généralement un événement submit ou blur, lit les inputs, et les exfiltre vers un hôte contrôlé par l'attaquant, souvent déguisé en requête d'analytics ou d'image. Le client ne voit rien. La commande aboutit, le reçu arrive, et les données de la carte sont déjà parties.

Magecart est le terme générique pour les groupes de menace et les kits d'outils qui mènent ces attaques à grande échelle. Le nom vient des premières campagnes contre les boutiques Magento, mais la technique est indépendante de la plateforme. Tout site qui affiche un formulaire de paiement ou de connexion est une cible, et le code du skimmer est souvent fortement obfusqué et change régulièrement pour échapper à la détection par signature.

Comment le skimmer arrive sur la page

L'injection passe rarement par votre propre code. Elle passe par quelque chose à quoi votre page fait déjà confiance.

Un script tiers compromis. Un widget de chat, une balise d'analytics, un snippet de test A/B ou un SDK de paiement est chargé depuis un fournisseur. Si ce fournisseur est piraté, ou son CDN, le fichier que vos clients récupèrent change et se met à skimmer. Vous n'avez rien déployé ; le script que vous incluiez déjà a fait le travail.
Un CDN ou une dépendance trafiqués. Un script que vous hébergez sur un CDN, ou un paquet de votre build, est altéré en amont. L'URL est la même, l'intégrité non.
Un tag manager détourné. Un outil dont la raison d'être est d'injecter des scripts fait un canal idéal. Un compte volé ou un éditeur aux permissions trop larges peut publier un skimmer sur chaque page sans toucher à votre dépôt, le scénario couvert dans le risque de sécurité de Google Tag Manager.
Une compromission côté serveur ou de la chaîne d'approvisionnement qui modifie directement le template de la page. Plus rare sur les sites qui reposent beaucoup sur des tiers, mais cela arrive.

Dans tous les cas, le code malveillant arrive par le même chemin que le code légitime, et c'est là toute la difficulté de la détection.

Pourquoi votre serveur ne le voit jamais

Un pare-feu applicatif web inspecte les requêtes et les réponses au niveau de votre origine. Un skimmer injecté via un script tiers ne passe pas du tout par votre origine : le navigateur le récupère directement auprès du fournisseur ou du CDN, l'exécute, et les données volées partent du navigateur vers l'hôte de l'attaquant. Rien de ce trafic ne touche vos serveurs.

L'analyse du code source a le même angle mort. Votre dépôt et votre pipeline de build semblent propres, parce que le changement s'est produit dans une dépendance que vous chargez à l'exécution, pas dans du code que vous avez commité. La page telle que le navigateur du client l'assemble n'est pas celle que votre CI a construite. C'est dans cet écart que se loge le formjacking, et c'est pourquoi les deux exigences de PCI DSS v4 qui visent cette menace demandent des preuves issues du navigateur, pas du serveur.

Détectez-le côté client

Si le navigateur est le seul endroit où le skimmer est visible, c'est là que la détection doit avoir lieu. Trois contrôles se complètent : une référence de ce qui s'exécute, une alerte quand cette référence change, et une policy qui limite ce qu'une injection passée entre les mailles peut faire.

Inventoriez chaque script qui s'exécute

Un inventaire de scripts est une liste structurée de chaque script que le navigateur charge et exécute réellement sur une page, propriétaire et tiers, construite à partir du reporting de hash CSP. CSP Level 3 permet au navigateur de calculer un hash de chaque script qu'il récupère et de le signaler. Vous obtenez donc la vraie liste, issue de vrais chargements de page, et non une estimation tirée de votre build. Avec la technologie, la version et les CVE connues rattachées, l'inventaire est votre référence de confiance : c'est l'ensemble des scripts qui ont leur place sur la page de paiement. Les mêmes données répondent aussi à une autre question, quelles bibliothèques de cette page portent une CVE connue ; voyez comment détecter les bibliothèques JavaScript vulnérables sur un site en production.

Alertez quand l'ensemble des scripts change

Une référence n'est utile que si vous êtes prévenu quand elle bouge. L'alerte de changement se déclenche quand les scripts d'une page sensible diffèrent de l'ensemble approuvé : une nouvelle origine, un nouveau bloc inline, un script qui n'était pas là hier, ou la même URL servant un hash différent. Sur une page de paiement, un script nouveau ou modifié est le premier signal d'un skimmer, toute la différence entre l'attraper en quelques heures et l'apprendre des semaines plus tard par un rapport de rétrofacturations. C'est la détection de changement et d'altération que l'exigence 11.6.1 de PCI DSS v4 impose aux pages de paiement.

Limitez l'injection avec une CSP stricte

La détection vous dit que quelque chose a changé ; une CSP stricte limite d'emblée ce que ce changement peut faire. Plutôt que de faire confiance à une liste d'hôtes, une policy stricte fait confiance à un nonce par requête et utilise 'strict-dynamic' pour étendre cette confiance uniquement aux scripts que votre code de confiance charge. Un attaquant qui trouve un point d'injection ne peut pas exécuter de script, faute de pouvoir deviner le nonce, et le navigateur ignore la liste blanche d'hôtes dont il aurait pu abuser.

Content-Security-Policy:
  script-src 'self' 'nonce-{SERVER-GENERATED-NONCE}' 'strict-dynamic';
  connect-src 'self' https://api.your-psp.example;
  object-src 'none';
  base-uri 'none';
  report-to csp-endpoint

Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"

Deux directives ajoutent une protection contre le formjacking. connect-src limite où la page peut envoyer des données, donc un skimmer qui essaie d'exfiltrer vers un hôte inconnu déclenche une violation au lieu d'un POST silencieux. base-uri 'none' bloque une injection de balise <base> qui redirigerait chaque URL de script relative vers un attaquant. C'est aussi dans les listes blanches d'hôtes que se cachent les contournements : une redirection ouverte ou un endpoint JSONP sur un hôte autorisé peut exécuter du code choisi par l'attaquant tout en respectant une policy laxiste, une raison de plus de préférer un nonce à une liste d'hôtes. Construisez la policy en commençant par Report-Only, comme le montre comment construire une CSP solide, et vérifiez un brouillon avec le scanner CSP gratuit.

Comment CentralCSP s'intègre

CentralCSP ingère vos reports de violation et de hash CSP, construit l'inventaire de scripts pour chaque page, et alerte quand l'ensemble des scripts ou les headers de réponse changent. Un skimmer déployé via un fournisseur compromis ou une balise malveillante apparaît comme une alerte « nouveau script sur la page de paiement », avec l'origine et le hash, plutôt que comme une plainte client plus tard. Associez cela à la suite CSP pour appliquer une policy stricte, et vous tenez les deux moitiés : limiter ce qu'une injection peut faire, et le savoir au moment où elle apparaît.

Vous pouvez évaluer votre policy actuelle à la recherche de points faibles comme des listes blanches d'hôtes trop larges, puis démarrer un essai gratuit et faire pointer vers CentralCSP un header Report-Only depuis vos pages de paiement, pour voir ce qu'elles chargent vraiment avant de passer à l'application.

Foire aux questions

Qu'est-ce que Magecart ?

Magecart est le nom des groupes de menace et des kits d'outils qui volent les données de cartes de paiement en injectant du JavaScript malveillant (un skimmer) dans les pages de paiement. La technique consistant à lire les champs de formulaire et à les exfiltrer s'appelle le formjacking. Le code arrive généralement via un script tiers, un CDN ou un tag manager compromis.

Comment détecter un skimmer de formjacking ?

Du côté du navigateur, parce que c'est le seul endroit où le skimmer est visible. Construisez un inventaire de scripts de chaque script qui s'exécute sur la page de paiement, alertez quand cet ensemble change (une nouvelle origine, un nouveau bloc inline, un hash modifié), et exécutez une CSP stricte pour qu'une injection ne puisse ni s'exécuter ni exfiltrer discrètement. Les logs serveur et les analyses de code source passent à côté.

Pourquoi un pare-feu applicatif web rate-t-il Magecart ?

Un pare-feu inspecte le trafic au niveau de votre origine. Un skimmer chargé via un script tiers s'exécute dans le navigateur et envoie les données volées directement du navigateur à l'attaquant, sans jamais passer par vos serveurs. La page que le navigateur du client assemble diffère de celle que votre build a produite, et c'est dans cet écart que se loge le skimmer.

Une CSP arrête-t-elle Magecart ?

Une CSP stricte qui fait confiance à un nonce et à 'strict-dynamic' plutôt qu'à des listes blanches d'hôtes empêche une injection extérieure d'exécuter un script, et connect-src limite les destinations vers lesquelles les données peuvent partir. Elle n'arrête pas un skimmer déployé via un script auquel vous faites délibérément confiance, et c'est pourquoi la détection (inventaire plus alerte de changement) forme l'autre moitié.

À retenir

Magecart et le formjacking volent les données de carte avec du JavaScript qui se charge exactement comme vos vrais scripts, donc le serveur ne le voit jamais. La détection doit venir du navigateur : un inventaire de scripts comme référence, une alerte de changement quand un script nouveau ou modifié apparaît sur une page de paiement, et une CSP stricte qui empêche d'emblée une injection de s'exécuter ou d'exfiltrer. Ces contrôles transforment un changement invisible côté client en une alerte sur laquelle vous pouvez agir.

Pour aller plus loin : OWASP sur la sécurité côté client et des recherches d'éditeurs de sécurité sur le web skimming comme l'analyse d'Akamai des campagnes Magecart.

Magecart et formjacking, comment détecter un skimmer côté client