Les cybercriminels en raffolent : les attaques par écrémage (ou “skimming” ou “Magecart”) ont le vent en poupe ces dernières années pour dérober les données sensibles associées aux cartes de paiement de leurs victimes. A la clé, ce sont l’ensemble des entreprises de vente en ligne qui sont exposées. Afin de lutter contre ce nouveau risque, les acteurs du e-commerce ont tout intérêt à entamer sans attendre leur parcours de mise en conformité.
Comme des millions de Français, vous faites votre shopping sur les sites de commerce en ligne. Il faut dire qu’ils sont pratiques et qu’ils font gagner un temps précieux. Et vous n’iriez pas acheter sur des plateformes douteuses, susceptibles de vous arnaquer et de voler vos données confidentielles.
Sauf que les attaques cyber ont bien évolué depuis l’avènement d’Internet, et avec elles les compétences des fraudeurs, qui sont capables d’exécuter des attaques via des sites web qui semblent sûrs et légitimes, à tel point que les utilisateurs ne sont tout bonnement pas en mesure de savoir que leurs données confidentielles ont été dérobées. Aussi, il faut parfois très longtemps pour comprendre que la faille réside dans un script malveillant qui a été hébergé sur une page de paiement en ligne bien légitime. On peut se souvenir à cet égard de British Airways et Emma Literie : les escrocs ont extrait les données des cartes bancaires de respectivement,380 000 et 94 000 clients. L’impact business est rapidement important avec un risque direct pour les clients, potentiellement des amendes, et pertes possibles de chiffre d’affaires et de réputation pour les entreprises concernées.
Sites de e-commerces : comment faire face à la vulnérabilité intrinsèque des formulaires web ?
Si l’on en croit les nouveaux rapports de Verizon et IBM, 90 % des fuites de données impliquaient en 2021 une application web, et 44 % incluaient des informations personnelles. En cause, en partie, un langage Javascript omniprésent sur Internet, qui offre un large champ d’attaques, notamment au travers des parties tierces, applications ou services existants réutilisés dans la construction de nouveaux services ou sites web. Dans les faits, au moins 70 % des scripts proviennent de parties tierces, voire de “quatrièmes parties”. L’activité des sites peut très vite devenir chargée, et le script malveillant enfoui peut apparaître comme par surprise, avec le but évident de voir le Javascript malveillant exécuté au niveau du navigateur utilisateur pour en extraire les données sensibles comme des informations bancaires.
Pour faire front, les entreprises ont concentré leurs efforts de protection côté serveur “interne” de l’entreprise. Il faut toutefois également sécuriser le navigateur côté client si on veut assurer la protection directe des utilisateurs de services web et le bon déroulement des activités du site de e-commerce.
PCI DSS : le standard mondial pour encadrer la protection des données bancaires contre les attaques illicites
Face à cette vulnérabilité intrinsèque des formulaires web, un standard mondial existe pour encadrer la protection des données bancaires contre les attaques illicites : la norme PCI DSS. Du fait de la sophistication des attaques, cette norme dans sa nouvelle version (v4) s’enrichit de 64 nouvelles exigences, dont deux incontournables pour prévenir et détecter les attaques par écrémage lancées sur les sites de vente en ligne.
La première, l’exigence 6.4.3, a pour objet de réduire la surface d’attaque. Elle garantit la véritable nécessité des éléments JavaScript contenus dans une page de paiement. Elle assure également qu’ils sont inclus dans un inventaire et qu’ils ont été explicitement approuvés. Ce qui nécessite bien sûr l'assurance de l'intégrité de tous les JavaScript.
La seconde incontournable à cet égard est l’exigence 11.6.1, relative à la détection de toute falsification du code JavaScript inclus dans les pages de paiement. Il faut pour cela que les modifications apportées aux scripts et aux en-têtes de page « http Headers » puissent être détectées, et que les alertes correspondantes soient générées. Un contrôle dynamique devra également être effectué périodiquement et/ou sur une fréquence de maximum 7 jours.
Nouvelle version : quelles mesures pour être conforme ?
Dans ce contexte, l’obligation pour les e-commerçants propriétaires de sites et les fournisseurs de services de paiement est claire : ils doivent être en mesure d’assurer une visibilité et une gestion complètes de la totalité des scripts chargés sur la page de paiement. Ainsi, pour entrer en conformité, ils vont devoir mettre en place des solutions et outils variés pour atteindre cet objectif autour d’actions clés : générer un inventaire, autoriser les scripts présents, valider leur nécessité, garantir l’intégrité des scripts, alerter si nécessaire, vérifier les changements de contenu de page active qui pourraient affecter la procédure de paiement, ou encore détecter les changements d’en-têtes http.
Ces nouvelles exigences seront obligatoires à partir du 31 mars 2025, et bien que l’ancienne version (V3.2.1) reste valide encore deux ans le temps de la migration, les sites de e-commerce ont tout intérêt à ne pas attendre pour entamer leur mise en conformité. Bien accompagnés, ils disposeront ainsi en amont d’une visibilité, d’une capacité de gestion des risques et d’une possibilité de contrôler le code JavaScript beaucoup plus fine. D’autant que la fréquence et le degré de sophistication de ce type d’attaque va sans aucun doute encore augmenter d’ici à ce que les nouvelles conditions soient mises en œuvre dans l’écosystème de paiements. Alors mieux vaut prévenir que guérir, et mettre toutes les chances de son côté lorsque le grand jour sera arrivé.
*Verizon 2021 et IBM Data breach report.
Tribune par Hervé Hulin, Directeur régional des ventes France de Jscrambler.