Web Skimming : Comment les Attaquants Volent les Donnees de Cartes de Credit de Votre E-Commerce

Quelque part en ce moment, une petite boutique e-commerce traite des commandes normalement. La page de paiement fonctionne, les paiements passent, les clients recoivent leurs produits. Tout semble normal. Mais sur chaque commande, quelques lignes de JavaScript injecte copient silencieusement le numero de carte, la date d'expiration, le CVV et le nom du titulaire pour les envoyer a un serveur controle par des criminels.

C'est le web skimming. Aussi appele attaques Magecart, formjacking ou skimming numerique de cartes. C'est l'equivalent en ligne des dispositifs skimmer physiques que les criminels fixent sur les distributeurs automatiques. Sauf que c'est invisible, cela s'etend a des millions de transactions, et la plupart des victimes ne savent jamais que cela se produit.

Comment Fonctionne le Web Skimming

Keylogging

Le script injecte attache des ecouteurs d'evenements aux champs du formulaire de paiement. Chaque frappe est capturee et enregistree. Les scripts de skimming sont fortement obfusques pour eviter la detection.

Form Grabbing

Le script intercepte l'evenement de soumission du formulaire. Quand le client clique "Payer," le script capture toutes les valeurs du formulaire avant ou en meme temps que la soumission legitime.

Injection d'Iframe

L'attaquant remplace le formulaire de paiement legitime par un faux rendu dans un iframe. Le faux formulaire est identique au vrai. Le client entre ses details de carte dans le formulaire de l'attaquant.

Attaques par Superposition

L'attaquant superpose un formulaire invisible ou transparent sur le formulaire legitime. Le client pense taper dans le vrai formulaire, mais son input va d'abord a la superposition de l'attaquant.

Comment les Attaquants Inserent Leur Code

1. Compromission Directe du Site

L'attaquant exploite une vulnerabilite dans la plateforme e-commerce (CMS non a jour, plugin vulnerable, identifiants admin faibles).

2. Compromission de Scripts Tiers

Beaucoup de pages de paiement chargent des scripts de services tiers : analytics, tests A/B, widgets de chat. Si l'attaquant compromet un de ces services, son code tourne sur chaque site chargeant le script compromis.

Pour une analyse plus approfondie, consultez notre article sur les risques du JavaScript tiers.

Cas Reels

British Airways (2018)

Les attaquants ont compromis un fichier JavaScript et injecte un script de skimming capturant les details de carte sur les pages de reservation. L'attaque a dure environ deux semaines et a affecte environ 380 000 transactions. Amende de 20 millions de livres sous le RGPD.

Ticketmaster (2018)

Ticketmaster chargeait un chatbot d'un fournisseur tiers. Les attaquants ont compromis les serveurs du fournisseur et modifie le fichier JavaScript. Les serveurs de Ticketmaster n'ont jamais ete directement compromis : c'etait une attaque supply chain.

Petits Sites E-Commerce

La vaste majorite des attaques ciblent de petits sites. Un petit magasin en ligne traitant 50 commandes par jour est une cible viable. Si le skimmer tourne pendant trois mois, cela represente environ 4 500 numeros de cartes voles.

Exigences PCI DSS

PCI DSS 4.0 et Securite Cote Client

• Exigence 6.4.3 : Tous les scripts de page de paiement charges et executes dans le navigateur du consommateur doivent etre geres. Vous devez maintenir un inventaire, justifier chaque script et implementer des controles d'integrite.
• Exigence 11.6.1 : Un mecanisme de detection des modifications doit etre deploye sur les pages de paiement.

Comment Detecter le Web Skimming

1. Rapports CSP

Deployez une Content Security Policy avec rapports. Quand un skimmer essaie d'envoyer des donnees volees a un domaine non autorise, la CSP le bloque et envoie un rapport.

2. Subresource Integrity (SRI)

Ajoutez des hashs d'integrite a tous les scripts externes sur les pages de paiement.

3. Audit Regulier des Scripts

Verifiez periodiquement tous les scripts qui tournent sur votre page de paiement via les outils developpeur.

4. Surveillance de l'Integrite des Fichiers

Surveillez les fichiers de votre site pour les modifications non autorisees.

Defense : Content Security Policy

La CSP est la defense la plus efficace contre le web skimming. Meme si un attaquant injecte un script, il ne peut pas envoyer les donnees volees car la CSP bloque les connexions sortantes vers des domaines non autorises.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://votre-provider-paiement.com;
  connect-src 'self' https://api.votre-provider-paiement.com;
  frame-src 'self' https://votre-provider-paiement.com;
  object-src 'none';
  form-action 'self' https://votre-provider-paiement.com;

Defense : Traitement des Paiements Cote Serveur

La defense architecturale la plus efficace est de ne jamais faire passer les donnees de carte par le frontend de votre site. Des fournisseurs comme Stripe, Adyen et PayPal offrent des pages de paiement hebergees ou de la tokenisation.

Avec une page de paiement hebergee, le client entre ses details de carte sur le domaine du fournisseur, pas le votre. Meme si votre site est completement compromis, l'attaquant ne peut pas skimmer les donnees de carte car elles n'apparaissent jamais sur vos pages.

Pourquoi les Sites E-Commerce Suisses Sont des Cibles

• Valeurs de transaction plus elevees : Les consommateurs suisses depensent plus par transaction.
• Sensibilisation a la securite plus faible : Beaucoup de sites e-commerce suisses n'implementent pas CSP, SRI ou d'audits de securite reguliers.
• Plateformes obsoletes : Nous trouvons regulierement des sites avec des versions obsoletes de Magento, WooCommerce ou PrestaShop.
• Facteur de confiance : Les domaines suisses inspirent confiance. Les donnees de cartes volees de sites suisses ont des prix plus eleves sur les marches noirs.

Responsabilite Financiere et Juridique

Financiere

• Amendes PCI DSS : $5 000 a $100 000 par mois
• Couts d'investigation forensique : CHF 20 000-100 000
• Couts de reemission des cartes
• Perte du traitement des paiements

Juridique

• RGPD / nLPD : obligations de notification
• Responsabilite civile
• Dommage reputationnel

Que Faire Maintenant

1. Auditez votre page de paiement.
2. Implementez la Content Security Policy sur les pages de paiement.
3. Ajoutez des hashs SRI a tous les scripts externes.
4. Considerez les pages de paiement hebergees ou la tokenisation.
5. Mettez a jour votre plateforme e-commerce et tous les plugins.
6. Verifiez les exigences PCI DSS 4.0.

Pour un apercu complet des vulnerabilites d'applications web, consultez notre guide sur l'OWASP Top 10.

Si vous exploitez un site e-commerce et souhaitez une evaluation professionnelle de la securite de votre flux de paiement, contactez notre equipe. Nous aidons les entreprises suisses a proteger leurs boutiques en ligne et a se conformer aux exigences PCI DSS.