Comment détecter une attaque Magecart avec la supervision CSP

Un skimmer de type Magecart se trahit deux fois. D’abord au chargement : un script venu d’une origine jamais utilisée, une URL inédite sur une origine connue, ou un hash d’intégrité qui a changé sur un script déjà présent. Ensuite à l’exfiltration : un POST vers une origine que votre connect-src n’a jamais autorisée. La supervision CSP capte ces deux signaux depuis les navigateurs de vrais visiteurs, ce qui ramène la détection à quelques minutes là où ces attaques tournent d’habitude des semaines. Et si la connect-src est appliquée et stricte, le navigateur refuse purement la requête d’exfiltration.

La suite : l’anatomie de l’attaque, puis chacun de ces deux signaux en pratique.

L’anatomie d’une attaque Magecart

Le mode opératoire n’a pas bougé depuis dix ans. L’attaquant fait exécuter du JavaScript sur les pages où les numéros de carte sont saisis, par l’une de deux voies : compromettre un script tiers que le checkout charge déjà (un widget de chat, un tag analytics, un bundle servi par un CDN empoisonné), ou injecter un fragment directement, souvent via une faille de CMS ou de plugin.

Ensuite, le skimmer en fait le moins possible, volontairement. Il pose des listeners sur les champs du formulaire de paiement, collecte numéro de carte, expiration et CVV au fil de la saisie et expédie le tout vers un serveur contrôlé par l’attaquant. Le domaine d’exfiltration ressemble en général à un domaine légitime, de ceux qu’on ne remarque pas dans l’onglet réseau. Le paiement aboutit normalement. La conversion ne bouge pas.

Ce silence est tout le problème. Le skimmer de British Airways en 2018 a tourné environ deux semaines et touché des centaines de milliers de cartes, et bien des boutiques plus modestes en hébergent un pendant des mois. Comme rien ne casse, il ne reste qu’une chose à guetter : le changement.

Les deux signaux qui trahissent le skimmer

CSP en fournit exactement deux, et ils encadrent commodément l’attaque.

Le premier, c’est le chargement. Quelle que soit la voie d’entrée, le navigateur d’un vrai client finit par exécuter un contenu de script qui n’était pas là avant. Vu de CSP, cela prend l’une de trois formes : un script depuis une origine toute neuve, une URL de script inédite sur une origine déjà utilisée, ou une dérive de hash, c’est-à-dire un contenu qui ne correspond plus au SHA-256 connu à une URL existante. La dérive de hash, invisible pour une liste blanche d’URL, est précisément le scénario du tiers compromis.

Le second, c’est la connexion. Les données volées doivent quitter la page. Un skimmer qui envoie via fetch, XHR ou sendBeacon vers origine-attaquante.example déclenche connect-src. Un autre qui réécrit la cible du formulaire déclenche form-action. Ce signal est le plus fort des deux, parce qu’il part même quand le premier n’est pas parti : c’est le navigateur lui-même qui rapporte la tentative, depuis la machine du client, à l’instant où elle se produit.

En report-only, les deux signaux arrivent sous forme de rapports de violation. En mode appliqué, le second devient meilleur : le navigateur bloque la requête, les données de carte restent sur la page, et le rapport tient lieu de pièce d’incident plutôt que de notification de fuite.

La détection en pratique

Le Script Inventory de CentralCSP couvre le versant chargement. Il repose sur le hash reporting de CSP (report-sha256 et ses variantes sous les directives de script) : chaque script exécuté par un vrai visiteur arrive dans l’inventaire avec son origine, son URL complète et son hash d’intégrité. Pas d’agent sur le checkout, pas de crawler. Détail qui compte : détecter les navigateurs headless et servir un contenu propre aux scanners est devenu un comportement standard des skimmers, et un signal issu du trafic client réel y est insensible. La mécanique est détaillée dans notre article sur la détection des changements de scripts tiers.

Au-dessus de l’inventaire, des règles d’alerte notifient Slack, Microsoft Teams, Google Chat, Telegram, l’e-mail ou des webhooks HTTPS signés en HMAC dès l’ingestion du premier rapport. La règle « nouvelle origine de script », à l’échelle du site (Business, 129,99 €/mois, alertes illimitées), attrape le premier des trois signaux de chargement. Les deux autres, une URL inédite sur une origine connue et un hash modifié, sont attrapés sur les pages que vous avez déclarées comme pages de paiement (/checkout/* et les pages parentes de votre iframe) par la règle « script non justifié » du module PCI DSS de l’offre Scale (349,99 €/mois) : tout ce qui y apparaît sans justification passe en file d’attente et réveille votre astreinte quand le skimmer a quelques heures, pas quelques semaines. Le réglage fin, déploiements légitimes compris, est dans notre guide des alertes de scripts sur page de paiement.

Le versant connexion relève davantage de la politique que de l’outillage. Écrivez une connect-src qui liste uniquement les origines auxquelles votre checkout parle réellement (votre API, votre PSP, votre endpoint analytics) et appliquez-la. La liste est courte en général, et c’est ce qui rend cette directive si efficace sur une page de paiement. Chaque tentative d’exfiltration apparaît alors dans votre flux de violations comme un blocage connect-src vers une origine jamais vue.

Ce que la supervision CSP ne voit pas

Soyons honnêtes sur la frontière : CSP observe les chargements et les connexions. Pas le comportement. Elle ne vous dira pas qu’un script autorisé s’est mis à lire des champs de formulaire qu’il ne touchait jamais.

Le cas difficile, c’est le code malveillant livré dans un script déjà autorisé, à son URL habituelle, avec un hash que vous aviez validé, par exemple parce que l’éditeur était compromis avant même votre premier inventaire. La surveillance de hash n’a rien à signaler : de son point de vue, rien n’a changé. Deux choses couvrent ce trou. La connect-src appliquée arrête les données volées à la frontière, quel que soit le script qui a tenté l’envoi. Et un workflow d’autorisation de scripts oblige un humain à justifier chaque entrée avant qu’elle rejoigne l’ensemble autorisé.

Aucun des deux n’est optionnel quand la page encaisse des numéros de carte : sans le signal de connexion vous ratez le script de confiance empoisonné, sans celui de chargement vous apprenez la tentative de vol sans savoir quel script retirer.

Pourquoi PCI DSS en a fait des exigences

Les exigences 6.4.3 et 11.6.1 de PCI DSS v4 existent à cause de cette attaque précise, et elles sont obligatoires dans les évaluations depuis le 1er avril 2025. 6.4.3 formalise le versant chargement : un inventaire de chaque script des pages de paiement, chacun autorisé avec une justification métier écrite. 11.6.1 formalise le versant changement : un mécanisme de détection d’altération évaluant la page telle que le navigateur du consommateur la reçoit, au moins tous les sept jours. Une supervision continue côté navigateur satisfait le mécanisme et produit la preuve au passage. Chez CentralCSP, l’outillage destiné à l’assesseur (workflow de justification, inventaire par page, chronologie datée des changements, export CSV et PDF) est réservé aux plans Scale (349,99 €/mois) et supérieurs. Le détail est dans notre analyse de 6.4.3 et 11.6.1.

En résumé : un skimmer doit se charger et doit exfiltrer. Surveillez les deux depuis le navigateur, appliquez la politique de connexion, et une attaque conçue pour tourner des semaines en silence produit un message Slack en quelques minutes et, sur une page bien configurée, ne vole rien du tout. Le tableau complet du checkout, en-têtes de sécurité compris, est dans la surveillance CSP pour l’e-commerce.