Applications, sites et API
Particuliers et entreprisesVol de données dans une page de paiement
Web skimming / E-skimming
Un script de paiement compromis copie les données saisies par le client.
Je pense être concerné : que faire ?
Comprendre et agir
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
Une situation concrète
Un acheteur saisit sa carte sur une boutique connue. Un script ajouté à la page copie certains champs au moment de la saisie. Le paiement peut se dérouler normalement, ce qui rend le vol difficile à remarquer.
Comment cela fonctionne
Le web skimming vole discrètement les données saisies dans une page web, souvent au moment du paiement. Le code peut provenir du site piraté, d’une bibliothèque tierce ou d’un gestionnaire de balises détourné. L’attaquant peut viser la page affichée à l’acheteur sans modifier le serveur qui traite le paiement.
- La page reçoit un code intrus
Site ou composant compromis.
- La saisie est copiée
Souvent pendant un achat.
- Les données partent ailleurs
Le paiement peut rester normal.
Ce que vous pouvez faire
Vos premiers réflexes
Surveillez vos opérations bancaires et contactez la banque si des données de carte ont été exposées. Un vol dans une page de paiement peut ne laisser aucun signe visible pendant l’achat.
Si vous êtes responsable du service ou de l’organisation
Si vous exploitez la boutique, recensez les scripts réellement chargés sur la page de paiement et les destinations qu’ils contactent. Protégez les comptes des prestataires qui peuvent modifier la page.
Un paiement réussi et une connexion HTTPS ne prouvent pas que les données n’ont pas été copiées dans le navigateur.
À vous de décider
Le paiement a réussi sur le vrai site en HTTPS. Les données ont-elles pu être copiées ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Oui. Un script de la page peut copier les données avant leur envoi au paiement. HTTPS protège leur transport, mais n’empêche pas un code présent dans la page de lire le formulaire auquel il a accès.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Un script ajouté à la page de paiement collecte des données
Les données sont copiées dans le navigateur, souvent pendant un paiement. L’attaquant peut avoir modifié le site, une dépendance JavaScript ou un gestionnaire de balises. Le vol peut donc se produire avant l’envoi prévu, sans que le serveur de paiement ait lui-même été piraté.
Dans ce cas, le fichier principal du site n’a pas changé, mais une révision du gestionnaire de tags ajoute un script. Surveiller uniquement le dépôt de l’application aurait donc manqué cette modification. Il faut inventorier ce que le navigateur charge réellement, avec les versions, les origines et les destinations réseau.
La présence d’un script nouveau ne prouve pas qu’il a lu des numéros de carte. Examiner les champs auxquels il peut accéder et les requêtes qu’il émet. Si les données sont saisies dans une iframe d’une autre origine, la page parente ne peut normalement pas lire son contenu ; elle peut toutefois ajouter un faux formulaire ou modifier le parcours autour de cette iframe.
Retirer le script coupe la collecte visible, mais il faut également reprendre le contrôle du compte ou du canal qui l’a publié. La période d’exposition dépend des versions effectivement servies, y compris celles conservées dans les caches.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Ajout de code HTML dans le gestionnaire de balises
Publication tiers vers Page marchande
Trace rev89
- Action sur place
Chargement de collect.js
Page marchande
Trace Inventaire navigateur
- Action
Affichage des champs hébergés
Page marchande vers Champ prestataire
Trace Frontière d’origine
- Action
Envoi des champs accessibles au parent
Page marchande vers Destination externe
Trace email / address
- Refus / blocage
DOM du prestataire non lisible directement
Champ prestataire vers Page marchande
Trace Same-origin policy
- Action
Retrait de la révision et fermeture de l’accès
Publication tiers vers Page marchande
- Refus / blocage
Contrôle des sorties après correction
Page marchande vers Destination externe
Trace CSP / observation
Comment repérer cette attaque
Indices à rechercher
- Un formulaire de paiement change sans modification autorisée.
- De nouveaux scripts ou domaines apparaissent dans la page.
- Des clients signalent des fraudes après des achats sur une même période.
Repérer les scripts absents du manifeste approuvé de la page de paiement et les envois vers de nouvelles destinations pendant la saisie du formulaire.
Quelles informations comparer
Relier la révision publiée au script effectivement chargé par le navigateur, puis à la requête sortante qu’il déclenche. Une connexion à un tiers doit être comparée aux intégrations autorisées.
Ce que ces indices ne permettent pas de conclure
Le journal du serveur marchand ne voit pas nécessairement un envoi direct du navigateur vers un tiers. Le nom d’un champ observé ne prouve pas que sa valeur a été transmise.
Comment réagir
Suspendre le canal de publication compromis, préserver les révisions et retirer les scripts non autorisés. Vérifier les comptes du gestionnaire de balises, les intégrations et les caches. Délimiter périodes, pages et données accessibles avec le prestataire de paiement avant de communiquer un périmètre de compromission.
Vérifier la correction
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- Chaque script présent sur la page de paiement doit avoir une justification et un responsable identifiés.
- Les nouvelles destinations d’envoi doivent être examinées avec les champs accessibles au script.
- Après retrait, les caches et le gestionnaire de tags doivent servir la version corrigée.
À vous de raisonner
Le dépôt du site est intact, mais un tag a ajouté un script à la page de paiement. Quelles observations permettent d’évaluer l’exposition ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Examinez les versions réellement chargées, les champs accessibles et les requêtes envoyées par le script. Sa présence seule ne prouve pas une lecture de carte, notamment si le paiement est dans une iframe isolée. Vérifiez aussi les faux formulaires possibles et sécurisez le compte qui a publié le tag.
Consulter les détails techniques
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-les dans les extraits.
fields- Résumé pédagogique des champs concernés, sans leurs valeurs. Un journal serveur ne fournit pas automatiquement cette observation faite côté navigateur.
Différence d’inventaire avant et pendant l’incident
JournalInventaire fictif du contenu réellement chargé côté navigateur, distinct de l’inventaire des fichiers serveur.
baseline page=/checkout script=checkout.js hash=sha256:VERSION_A owner=commerce
baseline page=/checkout script=tags.js hash=dynamic owner=marketing
observed page=/checkout script=checkout.js hash=sha256:VERSION_A
observed page=/checkout script=tags.js revision=rev89
observed page=/checkout script=collect.js origin=https://metrics.example.org
tag_audit revision=rev89 actor=marketing-admin change=custom_html_added
browser event=submit destination=https://metrics.example.org/ingest fields=email,addressPréparer une collecte dans votre environnement
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les secrets.
Chrome DevTools — panneau Network du navigateur
- Où les trouver
- Dans une capture déjà conservée, ou sur une reproduction autorisée en environnement de test : ouvrir Network et conserver la navigation avec Preserve log. Examiner Headers et Initiator.
- Quoi relever
- Dans une capture nettoyée de la page de paiement, inventorier les scripts et leurs initiateurs, puis les destinations réseau au moment de la saisie ou de l’envoi. Ne pas utiliser de vraies coordonnées bancaires pour reproduire.
- Accès et prérequis
- La capture doit être active pendant l’observation : elle ne reconstitue pas le passé. Un export HAR peut contenir des données privées, même après retrait des en-têtes sensibles ; le nettoyer avant partage.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Dans l’historique du gestionnaire de balises ou du CMS, relever auteur, révision, heure de publication et différence de code. Comparer les scripts à la version approuvée, empreintes comprises.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Dans l’histoire des cyberattaques
Groupes et campagnes documentés
Ces cas réels montrent où ce mécanisme a été observé. Les années indiquent quand les faits ont eu lieu. Chaque notice précise la source qui les relie à un groupe ou à une campagne.
- RéseauMagecart
MyPillow : un script espion au milieu du paiement
En octobre 2018, un script ajouté à la boutique MyPillow copie les informations de paiement. Un premier script est retiré, mais les attaquants gardent un accès. Ils en ajoutent un autre et le cachent derrière un domaine ressemblant à celui d’un service légitime.
Ce qu’établit la source. Microsoft documente ce cas dans sa présentation des investigations sur Magecart. Cette appellation recouvre plusieurs groupes de cybercriminels ; elle ne permet pas d’attribuer tous les vols de carte sur le Web à la même équipe.
Consulter le rapport Gather threat intelligence and perform infrastructure chaining — cas MyPillowMicrosoft Learn · Mis à jour le
Cette sélection ne couvre pas tous les incidents. Plusieurs acteurs peuvent utiliser une même technique. Les exemples fictifs de la fiche ne décrivent les actions d’aucun de ces groupes.
Si vous pensez être concerné
Si vous utilisez le service
Surveillez vos opérations bancaires et contactez la banque si des données de carte ont été exposées. Un vol dans une page de paiement peut ne laisser aucun signe visible pendant l’achat.
Pour l’équipe qui exploite le service
- Alertez le commerçant et votre banque en cas de données de carte exposées.
- Côté exploitant, retirez le code et fermez son point d’entrée.
- Identifiez les pages, périodes et visiteurs concernés avec les équipes compétentes.
Pour comprendre votre situation et trouver de l’aide : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- PCI Security Standards Council — pcisecuritystandards.org
- OWASP — Third Party Javascript Management — cheatsheetseries.owasp.org
- PCI SSC — Payment Page Security and E-Skimming — blog.pcisecuritystandards.org
