Skimmer Magecart PrestaShop : détecter et nettoyer une infection

Table des matières :

Un skimmer Magecart sur PrestaShop n’est pas « un virus générique » : c’est quasi systématiquement une injection JavaScript (souvent obfusquée) exécutée côté navigateur sur les pages de panier/checkout, dont l’objectif est d’aspirer des champs sensibles (CB, adresse, email, téléphone) puis d’exfiltrer ces données vers une infrastructure externe. En 2026, les campagnes Magecart visent autant les PSP « embedded » (formulaire carte dans la page) que les parcours redirigés (vol de session, d’email et de mot de passe), avec un focus sur les sites qui n’ont ni contrôle d’intégrité ni politique CSP.

Contexte versions : les exemples ci-dessous couvrent PrestaShop 1.7.8 / 8.x / 9.x (jusqu’à PrestaShop 9.1) avec PHP 8.1–8.3. Les chemins et templates varient selon le thème et les modules de paiement, mais les principes de détection sont constants.

Signaux faibles (et forts) d’une infection Magecart côté boutique

Le symptôme « classique » est une baisse brutale du taux d’acceptation paiement (erreurs, abandons), couplée à des retours clients sur des transactions frauduleuses. Techniquement, ce signal est tardif : un skimmer bien fait n’altère pas le DOM visible, et vise une exfiltration silencieuse via fetch(), XMLHttpRequest, navigator.sendBeacon() ou une image 1×1.

Pour éviter de réagir trop tard, surveillez aussi des signaux faibles qui précèdent souvent les plaintes :

Modifications “inexplicables” du checkout : un script supplémentaire, un fichier JS du thème mis à jour sans ticket, ou un module de paiement “réinstallé” récemment.
Différences entre appareils : certains skimmers ne s’activent que sur mobile (user-agent) ou uniquement si la langue / devise correspond (ex. fr_FR, EUR) pour réduire la détection.
Bruits applicatifs : pics de 404/302 vers des URLs non documentées, erreurs PHP sporadiques, ou vidage fréquent de cache var/cache/ (tentatives de persistance).

Deuxième catégorie de signaux : comportement réseau anormal depuis le navigateur. En DevTools (onglet Network) sur la page de paiement, vous observez des requêtes vers des domaines qui n’ont rien à faire là (TLD exotiques, sous-domaines qui imitent des CDN, endpoints type /collect, /pixel, /analytics). Une bonne partie des skimmers ajoutent aussi un fallback img.src = "https://…" + encodeURIComponent(data) pour contourner des restrictions CORS.

Astuce pratique : exportez un HAR (DevTools → Network → “Save all as HAR”) pour comparer avant/après nettoyage, et conservez-le dans votre dossier “preuve”.

Troisième catégorie : altération SEO / réputation. Un Magecart peut cohabiter avec du spam SEO (injections dans pages CMS, fichiers de sitemap, redirections), et déclencher un avertissement navigateur ou une alerte de sécurité. Si vous voyez des symptômes de pages vides/erreurs applicatives au passage, traitez-les comme des indicateurs de compromission possible (voir aussi les approches de diagnostic dans Dépannage boutique en ligne : 30 pannes classées par symptôme).

Enfin, côté conformité (France/UE), partez du principe qu’un skimmer implique un risque de violation de données (emails, adresses, parfois tokens de session). En UE, les obligations de notification peuvent s’appliquer selon les cas (RGPD, art. 33–34) : gardez une chronologie, des preuves, et une estimation du périmètre impacté. Texte de référence : Règlement (UE) 2016/679 (RGPD)

Réponse à incident : contenir avant de “nettoyer” (sinon vous perdez la preuve)

La plupart des boutiques contaminées font la même erreur : supprimer des fichiers au hasard ou « réinstaller PrestaShop » sans isoler, ni conserver d’artefacts. Or l’objectif n’est pas seulement d’enlever le skimmer, mais d’identifier le vecteur d’entrée (module vulnérable, cred admin compromis, RCE, SFTP exposé, CI/CD infecté). Sans ça, la réinfection arrive souvent en 24–72 h.

La méthode de base est celle de NIST SP 800-61. Citation exacte (NIST SP 800-61 Rev.2) :

“The incident response process consists of four phases: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity.”

NIST SP 800-61 Rev.2. Traduction opérationnelle : contenez (couper l’exfiltration), puis analysez, puis éradiquez, puis récupérez.

Concrètement, sur un checkout potentiellement skimmé :

Basculer en mode “paiement off” : désactiver temporairement les modules de paiement « embedded » (carte sur page), privilégier redirection PSP si possible. Si vous ne pouvez pas, mettez en maintenance courte avec page statique.
Snapshot (VM / volume / backup) avant toute modification. Si vous avez un pipeline GitOps ou Kubernetes, snapshottez aussi les images et manifests.
Sauvegarde “preuve” : archive du code + dump DB + logs (Nginx/Apache, PHP-FPM, auth, cron). Stockage hors serveur.

Pour gagner du temps (et éviter les oublis), conservez au minimum ces éléments, idéalement horodatés et hashés (SHA-256) :

Artefact	Pourquoi c’est utile	Exemple
Export HAR du checkout	Prouve l’exfiltration et les domaines	“Save all as HAR”
Liste des scripts chargés	Permet de recouper avec FS/DB	DevTools → Sources
Code source rendu (“View Source”)	Détecte l’injection server-side (avant JS)	Ctrl+U
Logs web + PHP	Remonte souvent au point d’entrée	`access.log`, `error.log`
`find` des fichiers modifiés	Repère la fenêtre d’attaque	`-mtime`, `-mmin`
Dump DB ciblé	Piste injections CMS/config	`ps_configuration`, `ps_cms_lang`

Si vous manquez d’accès serveur (pas de SSH/root) ou que vous êtes en mutualisé verrouillé, vous allez perdre du temps à cause de permissions/SFTP : anticipez via Erreurs SFTP : diagnostiquer connexion, authentification et permissions serveur.

Détection front : trouver l’injection JavaScript sur le tunnel de commande

Le Magecart “typique” s’accroche à des événements formulaire : submit, change, keyup, ou directement à des champs identifiables (input[name=cardnumber], #payment-form, iframes). Sur PrestaShop, les points d’injection fréquents sont :

fichiers thème : themes/<theme>/templates/checkout/*.tpl, themes/<theme>/assets/js/*, templates/_partials/*
surcharges : override/controllers/front/*, override/classes/*
modules : modules/<module>/views/js/*, modules/<module>/<module>.php, modules/<module>/override/*

Commencez par diff sur les fichiers chargés sur checkout. En pratique : chargez la page panier/commande, notez les scripts dans Sources (DevTools), puis cherchez dans le FS.

Exemples de patterns à grep (SSH requis) :

# ripgrep est plus rapide que grep
rg -n "atob\(|btoa\(|String\.fromCharCode\(|eval\(|Function\(" -S themes modules override
rg -n "sendBeacon\(|fetch\(|XMLHttpRequest\(|\.src\s*=\s*'https?://" -S themes modules
rg -n "on(?:submit|change|keyup)\s*=" -S themes

Ne vous faites pas piéger : beaucoup de skimmers 2024–2026 utilisent une obfuscation « propre » (tableaux de strings, XOR, crypto.subtle), et évitent eval. Cherchez aussi les domaines : exportez la liste des hosts vus dans Network, puis :

rg -n "suspicious-domain\.tld|/collect\b|/pixel\b|/gate\b" -S themes modules override

Si vous suspectez une injection “runtime” (script injecté via base de données), inspectez le HTML rendu (View Source, pas seulement DOM) pour repérer un <script> non attendu sur checkout. Les injections DB arrivent via contenus CMS, champs html de certains modules, ou hacks sur la table de configuration.

Deux vérifications simples qui évitent des fausses pistes :

Vérifier l’ordre de chargement : un skimmer est souvent placé après les scripts de paiement, pour “écouter” les événements. Dans DevTools, regardez le Initiator de la requête d’exfiltration (quel script l’a déclenchée).
Comparer hors cache/CDN : testez directement l’IP origin (si possible), ou désactivez temporairement le cache applicatif/CDN en “bypass” admin, car certains skimmers se servent du cache pour se propager (injection dans un fichier bundle minifié, puis servi à tous).

Détection back : intégrité du code, backdoors, DB et logs (là où le skimmer se cache)

Le cœur de PrestaShop ne fournit pas de contrôle d’intégrité ni de “baseline” de fichiers. Si votre boutique n’est pas gérée via Git, vous devez reconstituer une baseline : récupérez l’archive officielle de votre version (ex. 8.2.x / 9.1.x), puis comparez. Sur un serveur Linux :

# comparer rapidement l’arborescence avec une version “saine” décompressée à côté
rsync -a --dry-run --itemize-changes prestashop_sain/ prestashop_prod/ | head -n 200

# détecter fichiers récemment modifiés (à adapter)
find . -type f -mtime -14 -not -path './var/cache/*' -ls | sort -k7,8

Pour les backdoors, cherchez les classiques : fichiers PHP dans img/, upload/, download/, modules/<module>/ qui n’ont rien à faire là, noms pseudo-légitimes (class.php, cache.php, 1.php), et contenu du type base64_decode(gzinflate(...)), assert($_POST[...]), preg_replace('/.*/e', ...) (legacy). Un skimmer Magecart “front” est souvent accompagné d’une porte persistante “back” pour réinjecter après nettoyage.

Ajoutez aussi ces contrôles “pragmatiques” (très souvent payants en incident) :

Rechercher des écritures inattendues : un serveur correctement durci n’autorise pas l’écriture partout. Si vous trouvez des fichiers PHP modifiés dans des répertoires supposés statiques (ex. classes/, controllers/), c’est un indicateur fort.
Inspecter les fichiers minifiés/bundlés : un skimmer est parfois injecté dans un gros bundle *.min.js (thème ou module). Recherchez une “cassure” : un bloc de code anormalement long, ou une portion obfusquée qui n’existait pas dans le dépôt d’origine.

Côté base de données, les injections se logent souvent dans ps_configuration (valeurs HTML), tables de CMS (ps_cms_lang.content), ou tables de certains page builders. Exemple de requêtes de détection (MySQL/MariaDB) :

-- scripts inline dans les CMS
SELECT id_cms, id_lang
FROM ps_cms_lang
WHERE content LIKE '%<script%'
   OR content LIKE '%sendBeacon%'
   OR content LIKE '%atob(%'
LIMIT 200;

-- recherche large dans configuration
SELECT name
FROM ps_configuration
WHERE value LIKE '%<script%'
   OR value LIKE '%https://%'
LIMIT 200;

N’oubliez pas les logs. Un vecteur fréquent est un upload via endpoint vulnérable, observable dans les access logs (POST vers fichiers inattendus, 200/302 sur URLs obscures). Si vous centralisez les logs, OpenSearch aide beaucoup (voir OVHcloud Managed OpenSearch : moteur NoSQL managé pour logs et recherche). Pour la stack serveur (hardening/PMM), la base est détaillée dans Symfony : sécuriser un serveur PHP avec hardening et gestion CVE.

Point souvent oublié : corrélez heure d’apparition (première requête d’exfiltration, premiers fichiers modifiés) avec :

déploiements (CI/CD),
mises à jour modules,
connexions Back-Office (journaux admin si disponibles),
logs SSH/SFTP (si vous avez l’accès).

Cette corrélation est souvent ce qui fait la différence entre “nettoyage” et remédiation durable.

Nettoyage : éradiquer le skimmer Magecart sans casser la boutique

Phase 1 : restaurer une base saine du code. Si vous avez Git + CI/CD, la stratégie propre est : reset sur un commit connu, puis redeployer en immuable (container/artefact). Sans Git, l’approche la moins risquée est souvent de réinstaller le core depuis l’archive officielle de la même version en conservant app/config/parameters.php (selon version), .env (9.x), img/, upload/, download/ (à auditer), et votre thème/modules (à auditer un par un). Faites-le d’abord en staging (voir Staging PrestaShop : créer un environnement Docker fidèle à la production).

Phase 2 : supprimer la persistance. Liste minimale à traiter, sinon votre skimmer revient :

rotation de tous les mots de passe (Back-Office, FTP/SFTP, SSH, DB, panel hébergeur)
rotation des clés API (modules de paiement, tracking server-side, webhooks)
vérification des comptes admins ajoutés (tables ps_employee, ps_access), et des jetons
audit des crons (crontab système + crons applicatifs) et des tâches planifiées hébergeur

Sur PrestaShop 9/8, soyez attentif aux paramètres secrets et tokens. Si vous exposez des APIs (Admin API/Webservice), revoquez les clés et scopes (voir PrestaShop Admin API : sécuriser secret et scopes par client et API Webservice PrestaShop : guide CRUD et ressources développeur).

Phase 3 : nettoyage DB ciblé. Ne faites pas de REPLACE aveugle : vous allez casser du contenu légitime. Isolez les enregistrements qui contiennent du script, inspectez-les, comparez avec l’historique (si vous avez des dumps). Une bonne pratique est de :

exporter les lignes suspectes dans un fichier,
valider “ce qui est attendu” (ex. scripts de chat/support légitimes),
supprimer uniquement les charges malveillantes, puis contrôler le rendu côté front.

Et profitez-en pour vérifier le durcissement DB (TLS, privilèges minimaux, audit) : https://www.expertise-prestashop.fr/2026/08/13/securite-mysql-pare-feu-tls-privileges-minimaux-et-audit/.

Avant de remettre le paiement “embedded”, faites au moins un test de non-régression :

panier → commande → paiement (succès + échec),
mobile + desktop,
mode invité + compte client,
checkout multilingue si actif.

Prévenir la réinfection : CSP/SRI, monitoring, SBOM et discipline de mise à jour

Si vous “nettoyez” sans mettre de garde-fous, vous recommencez. Première barrière côté navigateur : Content Security Policy. Citation exacte (MDN) :

“Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.”

MDN — Content Security Policy (CSP). En PrestaShop, ça se déploie via en-têtes serveur (Nginx/Apache) ou module, mais attention : une CSP stricte sur checkout peut casser des PSP et scripts tiers. Procédez en Report-Only, collectez les violations, puis serrez progressivement.

Exemple (minimaliste) en mode observation, utile pour cartographier les scripts tiers avant de bloquer quoi que ce soit :

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' https:; connect-src 'self' https:; img-src 'self' https: data:; report-uri /csp-report" always;

Deuxième barrière : Subresource Integrity pour les scripts statiques. Citation exacte (MDN) :

“Subresource Integrity enables browsers to verify that resources they fetch (for example, from a CDN) are delivered without unexpected manipulation.”

MDN — Subresource Integrity (SRI). Appliquez integrity="sha384-…" + crossorigin="anonymous" sur vos scripts CDN. Ça ne couvre pas l’injection inline, mais réduit l’attaque supply-chain sur CDN.

Génération rapide d’un hash SRI (exemple) :

# calcule un sha384 SRI pour un fichier local (à adapter)
openssl dgst -sha384 -binary fichier.js | openssl base64 -A

Troisième barrière : industrialiser. Le combo réaliste en e-commerce :

SBOM et audit dépendances (modules, vendor PHP, assets front) + WAF (voir PrestaShop : sécuriser APIs et modules avec SBOM, WAF et CI/CD)
monitoring (Netdata/Prometheus) pour voir les pics de 404/POST, erreurs PHP, changements de fichiers (inotify/auditd) : Netdata : activer et configurer les collectors et Prometheus : alertes, métriques et requêtes PromQL
politique de mise à jour : tests en préprod + fenêtre de déploiement + rollback (voir Mise à jour PrestaShop : checklist sauvegarde, pré-production et tests)

Deux garde-fous “simples” à fort ROI, souvent négligés :

Réduire la surface d’écriture : si votre serveur permet à PHP d’écrire partout (thème, modules, core), vous facilitez la persistance. Un compromis courant : écriture limitée à var/, img/ (si uploads), et répertoires strictement nécessaires.
Désactiver / limiter les overrides non indispensables : les overrides sont puissants, mais ils augmentent la zone où un attaquant peut se cacher (et compliquent l’intégrité).

Enfin, acceptez une limite structurelle : PrestaShop (comme tout CMS e-commerce PHP) reste une plateforme extensible où la surface d’attaque est fortement corrélée au nombre de modules, overrides, scripts tiers. Si vous devez formaliser un plan de remédiation (preuves, chronologie, recommandations, durcissement), partez d’un audit méthodique (voir Audit sécurité PrestaShop : méthodologie, livrables et durcissement). Si vous êtes en incident actif et que votre équipe n’a pas le temps (ou l’accès) pour gérer confinement + forensic + redeploy propre, cadrez le périmètre d’une intervention via un contrat de run (voir PrestaShop maintenance : tarifs, niveaux de service et périmètre).

Checklist post-remédiation : valider que le skimmer a réellement disparu

Validation 1 (front) : sur un navigateur “propre”, ouvrez checkout et vérifiez que zéro requête ne part vers des domaines non listés (Network + export HAR). Faites la même chose en mobile (certaines injections ciblent des user agents). Si vous déployez CSP report-only, vérifiez qu’aucune violation “script-src” inattendue n’apparaît.

Validation 2 (back) : lancez un scan d’intégrité régulier. À défaut d’outillage avancé, un baseline sha256sum sur vos répertoires critiques (thème + modules + overrides) stocké hors serveur, puis comparé quotidiennement, attrape déjà beaucoup de réinjections.

Validation 3 (process) : documentez le vecteur d’entrée. Sans cette étape, la “solution” n’en est pas une. Les causes les plus courantes observées en PrestaShop : module obsolète, identifiants BO récupérés (phishing/credential stuffing), permissions laxistes (écriture sur trop d’arborescences), dépôt CI compromis. Une fois la cause identifiée, vous pouvez ajuster : MFA sur BO/panel, restriction IP admin, durcissement PHP-FPM/Nginx, et stratégie de déploiement immuable (utile aussi côté perf, cf. Symfony 7 : déploiement PHP-FPM Nginx, cache et opcache).

En complément, validez un “minimum vital” orienté business (souvent oublié alors que c’est ce qui rassure le plus) :

1 commande réelle (montant faible) sur chaque moyen de paiement activé, puis vérification côté PSP (webhook, statut).
Contrôle des comptes admin : aucun nouvel employee, MFA activé si possible, et suppression des accès inutiles.
Surveillance renforcée 7 jours : alertes sur modifications de fichiers, nouveaux endpoints appelés depuis le navigateur, pics de POST/404, et changements DNS inattendus. Si vous avez un incident “client-side”, les tentatives de réinjection sont souvent rapides.