Nous recevons cet appel régulièrement, et c’est toujours la même histoire. Une petite boutique en ligne, souvent sous PrestaShop, tourne depuis des années sur la même version, au nom du principe « on n’y touche pas tant que ça marche ». Elle a une iFrame ou une redirection vers son prestataire de paiement, elle valide donc avec le SAQ A, le plus court des questionnaires, et elle a lu cela comme « rien à protéger ».
Puis une vulnérabilité critique du vieux logiciel est exploitée. L’attaquant redirige les clients de la boutique vers une fausse page de paiement, ou installe un skimmer sur la vraie. Le prestataire de paiement voit les transactions chuter, comprend pourquoi, et suspend les paiements par carte. Sa lettre au commerçant dit : revenez avec un scan de vulnérabilités externe propre et une évaluation de conformité signée par un QSA. Le commerçant, qui perd désormais l’essentiel de ses ventes, nous appelle.
Trois boutiques
Trois cas récents, toutes de petites boutiques sur la même plateforme, toutes légitimement en SAQ A, toutes compromises. Dans l’un d’eux, l’attaquant n’a eu besoin d’aucune faille logicielle : il s’est connecté avec des identifiants administrateur volés mais valides, a installé un module avec une porte dérobée, puis des web shells, puis deux skimmers de cartes et un canal chiffré pour exfiltrer les données. Dans les trois cas, le point commun était une plateforme obsolète avec des vulnérabilités critiques connues, et des réglages serveur que personne n’avait regardés depuis l’installation : des mots de passe qui n’expirent jamais, root autorisé à se connecter en SSH, ce genre de choses.
Les commerçants disent tous la même chose au premier appel, presque mot pour mot : nous devons retrouver notre capacité à encaisser le plus vite possible, nous perdons des ventes. Personne ne pose de question sur le standard. C’est normal. Le standard, c’est notre travail ; le leur, c’est la boutique.
Ce que nous faisons, et dans quel ordre
Le commerçant est pressé. Il peut encore encaisser par d’autres moyens, mais pas par carte, et c’est l’essentiel de son chiffre d’affaires. Notre approche est donc rapide et, honnêtement, un peu brute. C’est aussi la bonne.
- Reconstruire depuis une sauvegarde saine connue. Pas « nettoyer ». Dès qu’un attaquant a eu un accès administrateur et installé des modules et des shells, vous ne savez pas ce qui s’y trouve d’autre. Reconstruisez, depuis une sauvegarde antérieure à la compromission, et passez directement à la version courante de la plateforme.
- Vérifier les exigences du SAQ A sur la boutique reconstruite. Le SAQ A est court, mais il n’est pas vide. Il interroge sur les comptes et mots de passe administrateur, sur la mise à jour du logiciel, et sur l’intégrité de la page qui remet le client au prestataire de paiement. Dans ces cas, chacun de ces points était le problème.
- Rédiger un court rapport de recommandations. Le jeu minimal de contrôles que le commerçant doit mettre en place pour signer le SAQ A en toute honnêteté, plus la poignée de choses que nous ferions de toute façon : une routine de mises à jour, un compte administrateur par personne, une sauvegarde réellement testée.
- Revenir quand c’est fait. Nous vérifions les corrections, lançons le scan externe, et libérons le SAQ A avec son attestation. Le prestataire réactive les paiements par carte.
Nous recommandons ; nous ne corrigeons pas. Les corrections sont généralement faites par l’agence web du commerçant, et c’est ainsi que cela doit être. Notre rôle est de dire ce qu’il faut, de vérifier que c’est fait, et de ne signer que lorsque ça l’est.
Dans la plupart des cas, le changement qui a le plus compté a été la mise à jour du logiciel de la boutique. Tout le reste était de l’hygiène autour.
L’hébergeur
Une partie de tout cela ne figure dans aucun questionnaire. Les petits commerçants et leurs hébergeurs ne parlent pas la même langue. Le commerçant connaît ses produits. Le support de l’hébergeur connaît sa plateforme, et répond dans ces termes. Restaurer une sauvegarde, changer un réglage serveur ou mettre à jour une version peut rester bloqué des jours sur ce fossé, pendant que la boutique perd des ventes. Nous intervenons parfois simplement pour traduire : voici ce dont nous avons besoin, voici pourquoi, voici le réglage. Ce n’est pas du travail d’évaluation. C’est ce qui remet la boutique sur pied.
Ce que l’on fait de travers
On lit « SAQ A » comme « le prestataire de paiement s’occupe de la sécurité ». Le questionnaire est court parce que le commerçant ne touche pas aux données de cartes. Mais le serveur qui sert l’iFrame de paiement ou la redirection est exactement ce que l’attaquant vise, parce que celui qui contrôle cette page contrôle où partent les données de carte du client.
On prend le scan externe pour la correction. Le prestataire le demande, donc il faut le faire, mais un scan réussi sur un serveur fraîchement reconstruit en dit très peu sur l’état de la boutique dans six mois. C’est la routine de mises à jour qui le fait.
On attend. Chaque semaine sur une vieille version est une semaine pendant laquelle une vulnérabilité publiée est recherchée par des gens qui font cela à grande échelle. Les boutiques touchées ne sont pas choisies. Elles sont trouvées.
Les boutiques touchées ne sont pas choisies. Elles sont trouvées.