Skimmer PrestaShop : reconnaître un voleur de cartes
Redirection vers une page carte inconnue, JavaScript ajouté à l'étape paiement, module fantôme : un skimmer PrestaShop copie la saisie. Notez l'URL, coupez ce chemin, prévenez banque et prestataire avec les dates. La home impeccable n'exclut rien.
Redirection vers une page carte inconnue, JS ajouté au checkout, module de paiement fantôme. Notez l'URL. Prévenez banque et prestataire avec les dates.
Reconnaître un voleur de cartes sur PrestaShop
Trois tableaux. (1) Le client quitte votre nom de domaine pour un lookalike ou une page « secure-pay » inconnue. (2) Il reste sur votre domaine, les champs carte s'affichent (alors que vous êtes en redirection PSP), et un script écoute. (3) Un module « Stripe » / « CB » que personne n'a posé intercepte l'étape. Les trois sont des skimmers au sens incident ; les preuves diffèrent (URL vs HTML vs dossier `modules/`).
Les clients disent « j'ai payé deux fois », « le site avait l'air bizarre », « ma banque a appelé ». Gardez leurs captures, barre d'adresse visible. Vous, en back-office, voyez souvent le tunnel « normal » (cache admin, IP bureau allowlistée). Testez déconnecté, mobile, depuis un réseau hors bureau.
Magecart n'est pas une marque sur votre facture. C'est le nom générique de cette famille. PrestaShop n'est pas plus « fragile » que Magento : il est fréquent, les modules nulled aussi. Cadre : PrestaShop, que faire et guide.
La redirection vers une page qui n'est pas le PSP
Notez l'URL complète (hôte, chemin, query). Comparez aux domaines officiels de votre prestataire (Stripe, PayPal, Payplug, Systempay, votre banque). Un sous-domaine que vous n'avez pas créé (`pay.votre-marque-secure.tld`) est déjà le constat. Coupez le module ou la règle qui y envoie — `.htaccess`, override, JavaScript `window.location`, configuration du module.
Ne « corrigez » pas en recréant un module depuis un zip reçu par email. Posez le module officiel, ou laissez le paiement off. Paiement redirigé.
Le JS injecté dans le checkout
Source de l'étape paiement : scripts dont le domaine n'est ni le vôtre, ni le PSP, ni votre GTM habituel. Un `jquery.min.js` hébergé sur un TLD de trois lettres, un pixel « analytics » inconnu. Les hooks PrestaShop (`displayHeader`, `displayFooter`, `displayPaymentTop`) et le thème (`theme.js`, `custom.js`) sont les logements. `ps_configuration` peut porter un extra HTML.
Les outils d'optimisation (Google Merchant, pixels, heatmaps) que vous n'avez pas posés : traitez-les comme injectés jusqu'à preuve. Un Hotjar inconnu exfiltre des enregistrements de session, cartes comprises si les champs ne sont pas masqués.
Le module de paiement fantôme
Un module activé, souvent un nom proche de l'officiel (`stripeofficial` vs `stripe_pro` vs `paypalv2`). Désactivez, zippez le dossier pour preuve, ne le mettez pas à jour. Comparez le checksum au zip Addons / GitHub éditeur. Un module nulled de paiement est une double peine : faille + skimmer déjà dedans. Stripe officiel vs nulled.
Les modules transport et « promo checkout » jouent le même rôle d'exécution PHP au tunnel. Module transport.
Ce qu'il faut figer tout de suite
Captures URL, HTML checkout, liste modules, employés récents, clés webservice, export commandes de la fenêtre, copie fichiers + base. Les journaux d'accès sur `/commande`, `/order`, `/module/`. Chez le PSP : journaux d'événements et liste des webhooks. Sans ça, la fenêtre de dates est une estimation, et le PSP demandera quand même ces pièces.
Stockez hors du serveur. Un zip dans `modules/` se corrompt avec le reste.
- URL + HTML checkout horodatés.
- Dump + archive fichiers.
- Export employés et clés.
- Journaux PSP / webhooks.
Couper sans perdre les commandes du jour
Paiement off, vitrine on. Les commandes déjà payées chez le vrai PSP restent à traiter (préparer, expédier) sauf fraude avérée. Les commandes « payées » uniquement chez le lookalike : vos clients ont payé un tiers — dossier PayPal / litiges ou banque, pas un simple avoir PrestaShop.
N'annulez pas en masse pour « faire propre ». Vous mélangez vrais clients et tests. Exportez, marquez, triez avec le PSP.
Où chercher dans les fichiers et la base
`modules/` inconnus, `override/`, thème `assets/js`, `js/` à la racine, `file_get_contents` / `curl` vers des hôtes inconnus, tables `ps_configuration`, CMS, hooks. Grep `<script`, `sk_live`, des emails que vous n'opérez pas. Employés et webservice : déjà cités, à faire dans la même vacation.
Un voisin de compte ou un WordPress sur le même FTP peut écrire dans `themes/`. Inventaire du compte, pas seulement du dossier PrestaShop. Voisin — le titre dit WordPress, le mécanisme est le même.
Banque, PSP, clients : le minimum
Dates, URL, volume, constat, canal incident du prestataire. Informer la banque, Stripe, PCI-DSS. Clients : fenêtre, relevés, pas de « zéro fuite » prématuré — que dire. CNIL : fuite, à vous de déclarer si dû.
Après le retrait : caches et réouverture
Caches PrestaShop (Performances), CDN, éventuellement LiteSpeed. Retestez le HTML checkout. Rouvrez un seul moyen de paiement officiel, test carte de test, puis le reste. Remettez les badges « paiement sécurisé » seulement après — mentions.
Service et déclaration : PrestaShop, créer un compte.
- Plus de redirection ni JS tiers inconnu au checkout.
- Module fantôme hors ligne, archive conservée.
- PSP informé, fenêtre écrite.
- Caches vides, test client propre.