L’évolution des attaques par « skimming » : Quelles sont les risques pour les victimes ?

Les attaques par écrémage (« skimming ») ou « Magecart » se sont imposées comme un outil de choix auprès des cybercriminels qui cherchent à voler les données sensibles de leurs victimes associées aux cartes de paiement. Toutes les entreprises de e-commerce /ventes en ligne sont aujourd’hui exposées à ce nouveau risque.
Comme l’attaque est exécutée via des sites Web qui semblent sûrs et légitime, les utilisateurs peuvent ne pas savoir que leurs données sont volées. Il faut parfois longtemps avant de comprendre que la faille réside dans un script malveillant hébergé sur une page de paiement en ligne légitime. British Airways et Emma Literie sont des exemples d’extractions de données de cartes bancaires avec respectivement 400 000 et 94 000 clients touchés.
En 2021, 90% des fuites de données impliquaient une application Web et 44% incluaient des informations personnelles (Sources : Verizon 2021 & IBM Data breach reports).
95% des sites Web et 55% des applications mobiles sont basées sur JavaScript.
Le langage Javascript étant omniprésent, il offre un large champ d’attaques notamment au travers des parties tierces, applications ou services existants réutilisées dans la construction de nouveaux services ou sites web. Très rapidement l’activité des sites peut devenir « chargée ».

En moyenne nous constatons que sur 35 composants, 70% des scripts d’un site Web e-commerce proviennent de tierces parties et même de « quatrièmes parties ». L’injection, plus ou moins enfouie, de script malveillant peut apparaître par « surprise ». L’objectif des attaquants est de voir leur Javascript malveillant exécuté au niveau du navigateur de l’utilisateur/client et d’extraire les données sensibles (exemple cartes bancaires). Les attaques peuvent arriver soit par le site Web propriétaire marchand, l’injection a été opérée directement sur les serveurs de la compagnie (cas British Airways), soit par celui du fournisseur de service de paiement. Il peut également passer par un autre service tiers (cas Ticket Master au travers du service « Chatbot »), ou bien par un « Tag Manager » (cas Adverline) qui gère des services tiers tels que la publicité, le profilage, le suivi/la localisation.

Les entreprises ont naturellement concentré leurs efforts de protection sur le côté SERVEUR « interne » à l’entreprise. Cependant, le côté CLIENT, c’est-à-dire celui du navigateur, reste à sécuriser pour assurer la protection directe des utilisateurs des services Web et le bon déroulement des activités du « propriétaire » du site Web.

Quelles sont les nouvelles exigences de ce standard ?

La norme PCI DSS (Payment Card Industry Data Security Standard) est un standard mondial qui encadre la protection des données bancaires contre les attaques illicites.
Face à la vulnérabilité intrinsèque des formulaires Web, la nouvelle version de la norme de sécurité des données, publiée par le Conseil des normes de sécurité PCI, renforce la protection des données de paiement avec de nouveaux contrôles et donc la résistance face aux cybers attaques sophistiquées.

La norme PCI DSS 4 s’enrichit de 64 nouvelles exigences dont deux visant à prévenir et détecter les attaques par écrémage lancées sur les sites de e-commerce :
● L’exigence 6.4.3 a pour objet de réduire la surface d’attaque. Elle garantit que tous les éléments JavaScript contenus dans une page de paiement sont nécessaires, qu’ils sont inclus dans un inventaire, et qu’ils ont été explicitement approuvés. Cela nécessite également l’assurance de l’intégrité de tout JavaScript.
● L’exigence 11.6.1 porte sur la détection de toute falsification du code JavaScript inclus dans les pages de paiement. Cela implique que les modifications apportées aux scripts et aux en-têtes de page « http Headers » puissent être détectées et les alertes correspondantes générées. Un contrôle dynamique doit être effectué périodiquement et/ou sur une fréquence de maximum 7 jours.

Quels sont les changements induits par cette nouvelle version ? Quelles mesures mettre en place pour être conforme ?

Les e-commerçants propriétaires de leurs sites et les fournisseurs de services de paiement devront assurer une visibilité et une gestion complètes de la totalité des scripts chargés sur la page de paiement. En outre, il leur faudra détecter les modifications apportées aux scripts existants — propriétaires ou tiers, sachant que près de 70% des scripts présents sur un site viennent de tierces parties.
La création d’alertes leur signalant en temps réel les modifications apportées aux scripts existants pourront les aider dans la gestion au quotidien. En détectant et évaluant les changements, ils seront en mesure de vérifier que personne ne tente de voler les données appartenant au titulaire de la carte.

Rentrer en conformité nécessitera de mettre en place des solutions ou outils permettant de :
• Générer un Inventaire.
• Autoriser les scripts présents
• Valider leur nécessité.
• Garantir l’intégrité des scripts (ils ne sont pas altérés).
• Alerter si nécessaire.
• Contrôler de manière périodique et/ou avec une fréquence de 7 jours.
• Vérifier s’il y a des changements sur le contenu de la page active qui pourraient affecter la procédure de paiement.
• Détecter les changements d’en-têtes http (Headers).

Dans une première approche, nous pouvons considérer la combinaison des méthodes standards CSP (Content Security Policy) et fonctionnalité de sécurité SRI (Sub-Resource Integrity) construits pour le Web. Ainsi les propriétaires de sites pourront déclarer les origines approuvées des contenus chargés par les navigateurs et valider que les services livrés sont sans manipulation inattendue.

Si toutefois elles peuvent couvrir les exigences de la norme, elles présentent néanmoins des inconvénients ou points faibles :
A propos des exigences 6.4.3 – CSP & SRI
• Générer un inventaire : procédure manuelle externe (tableur)
• Autoriser les scripts présents : procédure manuelle externe
• Valider la nécessité : procédure manuelle externe
• Garantir l’intégrité des scripts : Revue manuelle des fonctionnalités. Génération de « Hash » pour SRI.

A propos des exigences 11.6.1-CSP & SRI
• Alerter si nécessaire : CSP alerte, des analyses « scan » externes peuvent alerter.
• Contrôler de manière périodique et/ou avec une fréquence de 7 jours : CSP peut alerter en temps réel. Sinon analyse externe nécessaire.
• Vérifier s’il y a des changements sur le contenu de la page active qui pourraient affecter la procédure de paiement : SRI détecte les changements dans les scripts.
• Détecter les changements d’en-têtes http (Headers) : Analyse externe nécessaire.

De plus, il sera important de prendre en compte les informations suivantes :
• Chaque fois que la PSP (Prestataire de services de Paiement) modifie son JavaScript, vous devrez obtenir un nouveau hachage de sa part et mettre à jour votre page parent.
• Tout ajout de JavaScript à partir de nouveaux emplacements nécessite la modification du CSP, et cela peut ne pas correspondre aux flux de travail de l’entreprise.
• CSP & SRI présentent les inconvénients d’interventions manuelles. De plus, ils se basent sur des informations valables mais relativement « statiques ».

Des outils permettant une analyse dynamique, temps réel, des activités des scripts sur les différentes pages du site Web faciliteront la mise en conformité ainsi que son suivi. Par exemple, la solution Web Page Integrity de Jscrambler s’appuyant sur un agent sécurisé injecté dans les pages web à analyser, permettra de reporter en temps réel les activités des scripts sur un tableau de bord configurable afin d’automatiser les actions de contrôle et de sécurisation. La solution permet de :
• Générer un Inventaire. Un Inventaire est généré en temps réel dès qu’un script apparaît ou change.
• Autoriser les scripts présents. Il existe des champs pour enregistrer l’autorisation. De manière facultative, les scripts non autorisés peuvent être bloqués.
• Valider leur nécessité. La justification des scripts présents est inscrite dans le contexte de l’inventaire.
• Garantir l’intégrité des scripts (ils ne sont pas altérés). La fonctionnalité sera composée et le comportement de chaque script analysé.
• Alerter si nécessaire. Des messages d’alertes seront envoyés par email, par Slack et apparaitront dans le tableau de bord aussi via votre SIEM. 
• Contrôler de manière périodique et/ou avec une fréquence de 7 jours. Un contrôle peut être effectué en temps réel.
• Vérifier s’il y a des changements sur le contenu de la page active qui pourraient affecter la procédure de paiement. Les changements sont détectés en temps réel, signalés à partir des sessions, le comportement est analysé et le risque évalué.
• Détecter les changements d’en-têtes http (Headers). Les changements sont détectés en temps réel, et signalés à partir des sessions.
En plus du traitement complet des exigences 6.4.3 et 11.6.1, des outils comme celui de Jscrambler avec WebPage Integrity de par sa granularité de programmation pourront effectuer des actions de blocages ciblés.

Quel est le planning de mise en conformité ?

Ces nouvelles exigences seront obligatoires à compter du 31 mars 2025.
L’ancienne version de la norme (V3.2.1) restera valide pendant deux ans pour permettre aux organisations non seulement de se familiariser avec la nouvelle version, mais aussi d’avoir un temps de planification et de mise en œuvre.
Il est toutefois essentiel que les e-commerçants disposent en amont d’une visibilité, de capacités de gestion des risques et d’une possibilité de contrôler le code JavaScript. En effet, la fréquence et le degré de sophistication de ce type d’attaque devraient augmenter avant que les nouvelles conditions soient largement mises en œuvre dans l’écosystème de paiements.