A la préhistoire du ecommerce, pour effectuer le paiement, les boutiques réceptionnaient (capturaient) le numéro de carte bleue, puis transmettaient ce numéro de CB à la banque (son PSP pour être précis), lequel acceptait ou refusait le paiement. Les eShops étaient logiquement ciblés par les pirates : une prise de contrôle d’un eShop donnait accès aux numéros de carte de tous les paiements.
Pour endiguer le flot de vol de numéro cartes, la très contraignante certification PCI DSS a été imposée au marchands qui voulaient manipuler les numéro de carte. Ainsi la majorité des eShops a basculé vers une capture du numéro de CB externalisé sur la plateforme monétique du PSP, ce qui a eu pour effet de réduire fortement la pression sécuritaire sur les eShop.
Les nouvelles techniques de paiement « onsite » ont ouvert … de nouvelles techniques de piratage
Ces dernières années, le secteur du paiement en ligne est particulièrement dynamique et concurrentiel : de nombreux acteurs spécialisés dans le paiement en ligne sont venus concurrencer les banques en proposant des solutions plus flexible, plus intégrées, etc… Ces nouvelles approches ont généré de nouvelles idées chez les pirates, qui ont aboutit à de nouvelles techniques dont la porte d’entrée est à nouveau l’eShop.
Ces nouvelles techniques, que nous ne détaillerons pas pour des raisons évidentes de sécurité, sont basées sur l’une ou l’autre des logiques suivantes :
- Lorsque le numéro de carte bleue est capturée sur l’eShop mais par le PSP (grâce à un iframe ou tout autre solution d’inclusion de code) ; le pirate utilise du javascript pour copier le numéro de CB lors du paiement,
- Lorsque le numéro de carte bleue est capturée chez le PSP, le pirate modifie le connecteur de paiement pour capturer le numéro localement puis le réinjecter chez le PSP,
A noter que le pirate prendra particulièrement soin de ne pas perturber le paiement, ni l’eshop, pour que le vol de carte reste indétectable du porteur de carte comme du marchand (ou de son prestataire technique) pour plusieurs raisons : 1/ si le porteur s’en rend compte, il fait opposition sur sa carte et le numéro n’est plus utilisable 2/ si le marchand s’en rend compte, il corrige sa boutique et le temps investi par le pirate pour mettre en place le dispositif est perdu.
Vous pensez être l’abri car vous ne capturez pas le numéro de CB sur votre eShop ? Ou vous utilisez tel ou tel prestataire de paiement ultra sécurisé ? Il y a 5 ans oui, aujourd’hui vous vous trompez. Relisez les lignes ci-dessus : une fois que le pirate a compromis la boutique, il modifie le code du module de paiement ; ses possibilités sont donc infinies !
Des groupes structurés sont déjà à l’oeuvre : une forte augmentation des actions est détectée depuis le second trimestre 2022 sur PrestaShop comme sur les autres CMS ecommerce. Malheureusement, beaucoup d’acteurs n’ont pas encore intégré ce changement de paradigme.
Pourquoi cette pression sécuritaire sur les eShop ne fait que commencer ?
Imposer la certification PCI-DSS à tous les eShops est impossible tant cette certification est lourde. Par ailleurs, régler le problème du coté PSP sera pas possible puisque le dispositif est mis en place sur l’eShop. Les marchands et leurs prestataires doivent intégrer qu’il leur revient maintenant de sécuriser leurs infrastructures, et que la tâche ne va pas être simple.
Par ailleurs, il est fort probable que la responsabilité du marchand commence à être engagée, notamment en cas de négligence. L’obligation d’utiliser des logiciels « à jour » mentionné dans le RGPD n’est à notre avis qu’un prémices. Pour rappel, en cas de piratage d’eShop avéré, le marchand est déjà obligé de faire une déclaration à la CNIL et prévenir (tous) les clients victimes.
Comment le pirate fait-il pour prendre le contrôle des eShops et quelles bonnes pratiques mettre en place ?
Tout d’abord, on s’imagine souvent le pirate comme un as de l’informatique qui exploite des failles de sécurité ultra compliquées … La réalité est que la majorité (pas tous donc) des piratages passe par une analyse intelligente des faiblesses / négligences de la cible.
1 – L’accès via le back office
Pour se connecter à l’administration d’une boutique, il faut 3 informations : URL du back office, email et mot de passe. Deviner les 3 est impossible, mais avec un peu de réflexion, d’aide ou de chance, un pirate peut trouver un point d’entrée :
- Informations faciles à deviner
- Informations partagés avec des acteurs peu regardant
Précautions : imposer un mot de passe réellement sécurisé pour tous les utilisateurs du back office, changer de mot de passe régulièrement (tous les ans), une URL d’admin complexe, nettoyage des comptes admin réguliers, mise en place d’un module 2FA, etc…
2 – L’accès via l’hébergement
Il est peu probable que votre hébergeur se fasse lui même pirater, mais vos accès FTP, PHPMySQL, Adminer, etc… ont pu être partagés plusieurs fois notamment par email ou d’autres supports non sécurisés.
Précautions : pas d’accès FTP, MySQL, pas d’Adminer, changement de mot de passe sensibles réguliers + à chaque fois qu’un mot de passe a été partagé à un tiers
3 – L’accès via une faille de sécurité du CMS
Généralement, le CMS ecommerce (PrestaShop, Magento, etc…) lui même souffre de peu de failles, mais les extensions (modules, thème, plugin, etc…), utilisées en grand nombre par les marchands, sont les points d’entrée privilégiés.
Précautions :
- Mise à jour très régulières du CMS et de tous les modules présents (activés ou non) sur le serveur
- Si un module est déréférencé par le CMS, supprimez le immédiatement
- Si un module n’est pas / plus mis à jour régulièrement par l’éditeur, supprimez le immédiatement
- N’ajoutez jamais de module dont la provenance n’est pas 100% sûre ; au mieux le module contient des failles ou ne fait pas l’objet d’un suivi, au pire le module est lui même une backdoor.
- Limitez le recours aux modules (pour la sécurité autant que les performances)
- Supprimez du serveur systématiquement tout module qui n’est plus utilisé, même temporairement. Attention, il faut supprimer les fichier du serveur, la désactivation ou la suppression PrestaShop sans suppression des fichiers ne suffit pas.
- Les modules vendus quelques dizaines d’euro ne peuvent avoir les mêmes critères qualités que le CMS lui même
- Entourez-vous d’acteurs sensibilisés ; infogéreur spécialisé PrestaShop ainsi qu’une agence qui assure l’exploitation de votre boutique.
- Votre infogéreur doit surveiller le trafic et/ou mettre en place un firewall applicatif
- Votre agence doit mettre en place un stratégie de sécurité
4 – Autres conseils
Soyez attentif aux signaux faibles ; comportement inhabituel du site, messages clients, etc…
Sensibilisez votre équipe à la sécurité.
Plus d’articles à venir
Nous mettrons à jour cette section avec les chapitres suivants de ce sujet, qui, encore une fois, ne fait que commencer.