PCI DSS v4 : Détection des menaces de skimming Web avec les intégrations de paiement
Éditorial supplémentaire et commentaire de Gal Meiri et Emily Lyons
Synthèse
Dans le monde du commerce numérique, le processus de paiement est essentiel lors de la phase de paiement. Le traitement en ligne des informations sensibles relatives aux cartes de crédit des clients s'accompagne d'obligations de sécurité strictes définies par le Conseil des normes de sécurité de l'industrie des cartes de paiement..
La dernière version des normes de sécurité des données de l'industrie des cartes de paiement, (PCI DSS v4.0) comprend des exigences supplémentaires pour se protéger contre les menaces côté client, y compris les attaques de skimming Web.
Pour alléger certaines obligations de sécurité et les risques associés au respect des nouvelles exigences des normes PCI DSS v4,de nombreuses entreprises choisissent d'intégrer des fournisseurs de paiement tiers dans leurs opérations.
Dans cet article de blog, nous explorons les différents modèles d'intégration des fournisseurs de paiement, nous examinons les risques uniques côté client qu'implique chaque modèle et nous évaluons la vulnérabilité des organisations face aux menaces de skimming Web malgré le déchargement de leurs obligations PCI DSS envers ces fournisseurs tiers.
Comprendre les intégrations de paiement
Les intégrations de paiement sont essentielles pour les entreprises qui acceptent les cartes de paiement en ligne. En tant que point de connexion critique dans le processus de paiement du commerce numérique, elles fournissent aux entreprises un mécanisme pour autoriser les détails de la carte de paiement ou traiter la transaction en intégrant directement des méthodes de paiement dans un site Web.
Cela pourrait impliquer l'intégration d'un processeur de première partie, ou l'utilisation de passerelles de service marchand tierces, qui peuvent introduire des iframes ou rediriger l'utilisateur final vers son site pour la finalisation du paiement.
Attaques de skimming Web : une menace majeure pour le traitement des données de carte de crédit côté client
Les attaques de skimming Web font référence à une forme particulière de cyberattaque dans laquelle les pirates insèrent du code JavaScript malveillant dans des sites Web de commerce numérique (directement ou par l'intermédiaire de leurs fournisseurs tiers). Le but ultime de ces attaques est d'exfiltrer et de voler des données sensibles de l'utilisateur, telles que les numéros de carte de crédit et les détails de facturation personnels.
La cybercommunauté a été largement alertée de ces attaques pour la première fois en 2016 via un rapport suggérant qu'environ 6 000 plateformes de commerce numérique pourraient avoir été victimes de skimming Web. Nous avons depuis vu un nombre régulier de rapports sur les plateformes de commerce numérique qui ont été compromises par des techniques de skimming Web.
Le plus récent de ces rapports décrit une campagne de skimming Web style Magecart en cours,qui menace potentiellement les informations personnelles et financières de dizaines de milliers d'acheteurs en ligne de vols, d'abus ou de vente sur le dark Web.
Modèles d'intégration des fournisseurs de paiement côté client
Traitement direct des cartes de crédit
Dans ce modèle, le propriétaire du site Web gère l'expérience de paiement complète. Le formulaire de paiement intégré à la page de paiement collecte les informations de la carte de crédit et de la facturation saisies par l'utilisateur. Une fois la commande passée, les données sont directement envoyées aux serveurs du site Web pour traitement, généralement via l'API du fournisseur de paiement.
Intégration basée sur iframe
Dans ce cas, la responsabilité du processus de paiement est partagée entre le propriétaire du site Web et le fournisseur de paiement tiers. Une iframe, intégrée à la page de paiement du site Web, héberge le formulaire de paiement, qui est chargé à partir d'un domaine appartenant au fournisseur de paiement. Lorsque l'utilisateur termine son achat, les détails de la carte de crédit et de la facturation sont envoyés directement de l'iframe aux serveurs du fournisseur de paiement pour la finalisation de la transaction.
Rediriger le modèle
Dans ce scénario, le propriétaire du site Web et le fournisseur de paiement se partagent également les rôles. Le propriétaire du site Web supervise tous les aspects du paiement qui n'impliquent pas la collecte de données de carte de crédit. Lors de la passation de la commande, l'utilisateur est redirigé vers une page distincte appartenant au fournisseur de paiement.
C'est là que l'utilisateur saisit ses informations de carte de crédit et de facturation. Le paiement est traité du côté du fournisseur de paiement, et l'utilisateur est ensuite redirigé vers le site Web d'origine.
Risques côté client associés aux modèles de fournisseurs de paiement
Menaces de base de skimming Web
Dans le modèle de traitement direct des cartes de crédit, les attaques de skimming Web, telles que Magecart,sont relativement simples à mettre en œuvre. Ces attaques déploient un script malveillant sur la page de paiement du site.
Lorsqu'un utilisateur saisit ses informations de carte de crédit dans les champs de paiement, ce script indésirable capture les données. Il envoie ensuite ces informations sensibles à un domaine contrôlé par l'attaquant, permettant ensuite des activités frauduleuses.
Attaques sophistiquées de faux formulaires
L'attaque par "faux formulaire" est une variante plus complexe du skimming Web. Dans ce cas, un script malveillant s'exécute sur la page de paiement, un peu comme dans le modèle de base du skimming Web. Cependant, ce script masque le formulaire de paiement authentique, qu'il soit intégré dans une iframe ou lié au site du fournisseur de paiement, et le remplace par un formulaire contrefait (figure).
L'utilisateur, ignorant la supercherie, indique ses informations de carte de crédit. Le script indésirable collecte ensuite ces données et les envoie à un domaine contrôlé par l'attaquant pour une utilisation frauduleuse ultérieure. Après cela, le script affiche généralement un message d'erreur et révèle le formulaire de paiement réel, poussant l'utilisateur à saisir à nouveau ses informations.
Image : Dans une attaque de faux formulaire, le skimmer cache l'élément de formulaire original et affiche un faux élément à la place.
Nous avons vu cette technique évoluer à travers les récentes attaques de skimming Web.. Les pirates informatiques exploitent des techniques plus sophistiquées pour dissimuler du code malveillant et contourner les mesures de sécurité préventives, telles que les stratégies de sécurité du contenu, afin de cibler de nouvelles victimes et d'optimiser l'exfiltration des données sensibles.
Conclusion
Les acteurs des menaces de skimming Web sont de plus en plus sophistiqués au fil du temps, trouvant de nouvelles façons d'exploiter les processus de paiement de première partie et de tiers pour voler les informations des utilisateurs finaux, y compris les données de carte de paiement du côté client.
Quelle que soit l'intégration de paiement choisie, les entreprises disposant d'un processus de paiement numérique risquent d'être victimes de ces attaques. La délégation de la conformité PCI à un prestataire de paiement n'implique pas toujours une absence de responsabilité en cas de violation de données. Il est essentiel que les entreprises qui traitent les informations relatives aux cartes de paiement pensent au-delà de la conformité et mettent en œuvre des mesures de sécurité solides pour se protéger efficacement contre ces menaces et assurer la sécurité des transactions en ligne.
Comment Akamai peut vous aider
La solution Client-Side Protection & Compliance d'Akamai aide à protéger contre l'exfiltration des données des utilisateurs finaux et protège les sites Web contre les menaces JavaScript. Cette solution est conçue pour détecter les scripts malveillants et alerter les équipes de sécurité afin qu'elles réduisent les activités nuisibles en temps réel.
Grâce à des capacités de conformité PCI DSS v4.0 spécialement conçues,la solution Client-Side Protection & Compliance peut également aider les entreprises à répondre aux nouvelles exigences de sécurité des scripts pour protéger les données des cartes de paiement contre les attaques de skimming Web.
