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
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
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 est une collecte clandestine de données dans une page web, souvent au moment du paiement. Le code peut venir d’un site compromis, d’une bibliothèque tierce ou d’un gestionnaire de balises détourné. La fraude ne nécessite pas toujours de modifier le serveur de paiement lui-même : elle peut cibler l’écran que voit l’acheteur.
- 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
Commerçants : inventoriez les scripts réellement chargés sur la page de paiement et leurs destinations. Protégez aussi les comptes des prestataires capables de modifier cette 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 ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Oui. Un script compromis dans la page peut les copier avant leur envoi prévu. HTTPS protège le transport, pas les actions du code autorisé à lire le formulaire.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Un script ajouté à la page de paiement collecte des données
Le web skimming consiste à récupérer des données saisies dans le navigateur, souvent sur une page de paiement. L’attaquant peut modifier le site, une dépendance JavaScript ou un gestionnaire de tags. Le serveur de paiement n’a pas nécessairement été compromis : la collecte peut avoir lieu avant l’envoi prévu.
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.
Éléments à croiser
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.
Limites de l’interprétation
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
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- 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 ?
Formulez votre décision et l’élément qui la justifie 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
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-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
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des 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
Des faits réels pour situer ce mécanisme. Les années sont celles des faits ; chaque notice précise qui établit le lien avec le groupe ou la campagne.
- RéseauMagecart
MyPillow : un script espion au milieu du paiement
En octobre 2018, un script injecté dans la boutique MyPillow collecte les informations de paiement. Après le retrait d’un premier script, les attaquants conservent un accès et en ajoutent un autre, dissimulé derrière un nom de 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
Sélection de cas documentés, non exhaustive. Une technique peut être utilisée par de nombreux acteurs. Les cas fictifs de la fiche ne sont attribués à 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 qualifier votre situation et être orienté : 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
