Table des matières :
- Déclenchement : quand basculer en mode « incident » sur une boutique PrestaShop
- Préparer un plan exploitable (avant l’incident) : inventaire, accès et journaux
- Containment immédiat (0–60 min) : isoler, couper, et éviter l’auto-sabotage
- Acquisition de preuves et triage : timeline, IOCs, persistance (sans fantasmes)
- Éradication et remise en service : reconstruire proprement (souvent mieux que “nettoyer”)
- Post-incident : durcissement ciblé, contrôle d’accès, et obligations (RGPD/PCI)
Déclenchement : quand basculer en mode « incident » sur une boutique PrestaShop
Un plan de réponse à incident PrestaShop ne sert à rien si personne ne sait quand l’activer. Dans le monde réel, le déclencheur n’est pas “un log bizarre”, c’est un risque business immédiat : fuite de données clients, fraude paiement, compromission admin, ou persistance serveur. Le NIST résume le périmètre sans détour : “Incident response is the process of detecting, analyzing, containing, eradicating, and recovering from incidents.” (NIST SP 800-61 Rev.2, p. 1, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf). Sur PrestaShop, la difficulté est que le cœur n’apporte pas de mécanisme natif robuste de détection d’intégrité, ni de traçabilité admin “forensic-grade” : si vous attendez un signal parfait, vous perdez du temps.
Les signaux qui justifient un containment immédiat sont assez stables en 2026, notamment avec les webskimmers et infostealers côté serveur (voir votre propre panorama : Sécurité PrestaShop 2026 : webskimmers et infostealers côté serveur). Typiquement : modifications non planifiées de JS dans themes/*/assets/ ou modules/*/views/js/, apparition de fichiers PHP dans des répertoires d’assets, pics d’erreurs 500/503 en rafales, transactions “card testing”, ou création d’employés BO inconnus. Ajoutez les signaux infrastructure : connexions sortantes vers des domaines/ASNs atypiques, nouveaux cronjobs, nouveaux comptes système, ou escalade de privilèges via une vulnérabilité module.
Pour éviter les débats stériles (“c’est peut-être juste un cache…”), formalisez un seuil de bascule simple, basé sur l’impact :
| Signal observé | Risque principal | Décision par défaut |
|---|---|---|
| JS modifié sur checkout / panier sans déploiement | Skimmer, vol de données carte / session | Incident + coupure checkout (edge) |
| Nouvel employé BO / login admin suspect | Prise de contrôle, installation de persistance | Incident + verrouillage BO (IP/VPN) |
Fichiers PHP dans /img/, /upload/, assets thème |
Webshell, exécution distante | Incident + isoler serveur |
| Sorties HTTPS vers domaines inconnus depuis le serveur | Exfiltration | Incident + egress filtering |
Pic d’erreurs 500/503 + spikes POST sur /modules/ |
Exploitation en cours | Incident + WAF / blocage ciblé |
Mini-scénario réaliste (qui arrive plus souvent qu’on ne le pense) : un lundi matin, vous voyez une hausse d’abandons de panier et quelques clients signalent “un paiement refusé”. En parallèle, vos logs Nginx montrent des POST répétés vers un endpoint module. Même si vous n’avez pas encore “la preuve” d’un skimmer, l’incident est déjà business-critical : vous basculez en mode incident, vous coupez le checkout et vous lancez containment + acquisition.
La règle opérationnelle utile : séparer l’objectif “stopper l’hémorragie” de l’objectif “comprendre”. Le containment vise à casser la chaîne d’attaque et l’exfiltration, même si vous n’avez pas encore le vecteur exact. Le modèle SANS (toujours pertinent comme runbook) est clair : “The six steps of incident handling are: Preparation; Identification; Containment; Eradication; Recovery; Lessons Learned.” (SANS Incident Handler’s Handbook, https://www.sans.org/white-papers/incident-handlers-handbook/). Dans PrestaShop, containment d’abord, analyse ensuite—sinon vous laissez tourner un skimmer pendant que vous “regardez les logs”.
Préparer un plan exploitable (avant l’incident) : inventaire, accès et journaux
Sans préparation, votre “plan de réponse à incident” se résume à Slack + panique + modifications en production qui détruisent les preuves. Pré-requis minimum (à documenter et tester) : accès root ou sudo, accès lecture aux logs reverse proxy / webserver / PHP-FPM / MySQL, capacité à mettre en maintenance au niveau edge (CDN/WAF/HAProxy) et à prendre des snapshots (VM, volume, ou backup incrémental). Sur PrestaShop 8.1/9.x (PHP 8.2+ recommandé selon votre contexte ; attention aux incohérences de doc, voir PrestaShop 9 : versions PHP recommandées et incohérences de documentation), l’emplacement des secrets applicatifs (DB, cookie key) et des configs doit être connu (ex. app/config/parameters.php ou config/settings.inc.php) et protégé.
Deux détails “préparation” souvent négligés et pourtant critiques en forensic :
- Synchronisation horaire (NTP/chrony) sur tous les nœuds (reverse proxy, app, DB). Sans horodatage cohérent, votre timeline devient ambiguë.
- Runbook de contact : qui décide la coupure, qui parle au PSP, qui notifie (juridique/DPO), qui exécute les actions infra. Le plan n’est pas que technique.
L’inventaire n’est pas un exercice Excel : c’est une liste d’assets attaquables et de points de confiance. Elle doit inclure : version PrestaShop, thème, modules (source officielle vs ZIP), overrides, endpoints exposés (Webservice, API), jobs cron, accès SFTP/SSH, comptes BO, clés API, accès prestataires. Pour éviter un inventaire “mort”, ajoutez une colonne “action en incident” : quoi désactiver en premier, quoi isoler, quoi sauvegarder.
Exemple de grille d’inventaire utile (courte, actionnable) :
| Élément | Où c’est défini | Pourquoi c’est critique en incident |
|---|---|---|
Dossier BO (/adminXXXX/) |
FS + vhost | À restreindre par IP immédiatement |
| Modules paiement / checkout | /modules/ + config BO |
Cible fréquente de skimmers |
| Overrides | /override/ |
Permet d’injecter du code “propre” sans toucher le core |
| Crons applicatifs | cronjobs, modules, crontab |
Persistance + exfiltration silencieuse |
| Secrets (DB, cookie key) | app/config/parameters.php |
Vol = sessions compromises, pivot |
Pour la supply chain, coupler inventaire avec une validation de provenance/SBOM est un amortisseur direct (voir CI PrestaShop : provenance, SBOM et validation automatique des modules et PrestaShop GitHub : dépôts officiels, vérification et sécurité anti-forks). Un incident PrestaShop est très souvent un incident “module + accès admin + persistance”.
Côté logs, le cœur PrestaShop n’est pas suffisant : vous devez centraliser (ou au minimum conserver) : access logs (Nginx/Apache), error logs, logs PHP-FPM, logs MySQL/MariaDB, et idéalement audit système (auth, sudo, cron). Le but est double : (1) containment rapide (identifier IPs/URIs), (2) reconstruction de timeline.
Bon compromis “PME e-commerce” quand vous n’avez pas de SIEM : conservez au moins 30 jours de logs “chauds” (faciles à requêter) et archivez 3 à 6 mois en stockage moins cher, chiffré. Ce n’est pas une obligation universelle, mais c’est souvent le minimum pour investiguer une compromission découverte tardivement (ex. skimmer discret, exfiltration par petites quantités).
Pour mettre ça au carré, basez-vous sur des pratiques de monitoring/outillage déjà décrites sur le site : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail et Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes. L’objectif mesurable : réduire le MTTD (mean time to detect) et surtout le MTTC (mean time to contain). Concrètement : si votre équipe met 6 heures à “se mettre d’accord” avant de couper le checkout, vous n’avez pas un plan, vous avez une intention.
Containment immédiat (0–60 min) : isoler, couper, et éviter l’auto-sabotage
Le containment immédiat sur PrestaShop doit prioriser trois axes : (a) stopper l’exfiltration/fraude, (b) empêcher la persistance de s’étendre, (c) préserver les preuves. Première décision : maintenance totale ou mode dégradé. Si suspicion de webskimmer checkout ou d’injection front, vous ne gardez pas le checkout ouvert “pour continuer à vendre” : vous prenez le risque de collecte de PAN/cookies et de responsabilités PCI. Dans la pratique, la voie la plus sûre est de couper à l’edge (CDN / reverse proxy), car si l’attaquant a la main sur le serveur, la maintenance applicative peut être contournée.
Checklist opérationnelle (0–60 min) typique, à adapter :
- 0–10 min
- Décider : “incident” (owner clair).
- Passer en maintenance edge (ou limiter le checkout).
- Restreindre l’accès BO par IP/VPN (et idéalement MFA si en place).
- 10–30 min
- Capturer un snapshot (VM/volume) avant nettoyage.
- Geler les changements : stop déploiements, stop “hotfix” non tracés.
- Bloquer les sorties réseau non nécessaires (egress).
- 30–60 min
- Rotation des accès les plus exposés (BO, SSH/SFTP, API).
- Extraction rapide des IOCs (fichiers modifiés, endpoints frappés).
- Mise sous surveillance renforcée (WAF en blocage sur patterns confirmés).
Au niveau reverse proxy (Nginx/HAProxy/Cloudflare), servez une page statique de maintenance et autorisez uniquement des IPs d’admin (bastion/VPN). Exemple Nginx minimaliste (à adapter) :
# ATTENTION : à déployer via change contrôlé ; risque de coupure totale.
map $remote_addr $allow_admin_ip {
default 0;
203.0.113.10 1; # IP bastion/VPN
}
server {
# ...
if ($allow_admin_ip = 0) {
return 503;
}
error_page 503 @maintenance;
location @maintenance {
root /var/www/maintenance;
try_files /index.html =503;
}
}
Si vous devez rester en ligne (cas rare), le containment devient chirurgical : restriction de /adminXXXX/ par IP + Basic Auth, désactivation temporaire de l’upload et des endpoints sensibles, et durcissement WAF. Le WAF est souvent le seul moyen de bloquer rapidement une exploitation en cours sans redéployer : voir WAF PrestaShop : réduire les faux positifs et sécuriser le checkout. Pour les attaques volumétriques ou abus de facettes qui masquent des signaux, une couche fail2ban côté logs peut aider à stabiliser la plateforme (voir PrestaShop sécurité : bloquer la navigation à facettes via fail2ban).
Ensuite, containment côté secrets : rotation immédiate (dans cet ordre) des accès BO, SSH/SFTP, DB (si possible sans casser), clés API, tokens modules paiement, et cookies key si vous suspectez un vol de app/config/parameters.php (impact : déconnexion de sessions, à anticiper). Deux précisions qui évitent des “rotations inutiles” :
- Si votre serveur est compromis, changer un mot de passe BO sans restaurer un environnement sain ne suffit pas : l’attaquant peut relire le nouveau secret (ex. webshell).
- Si vous suspectez un skimmer, priorisez les identifiants et tokens liés au paiement (PSP/back office du prestataire) et les accès capables de modifier le front (BO, FTP, CI/CD).
Coupez aussi les sorties réseau non nécessaires (egress filtering) : un skimmer moderne exfiltre via HTTPS vers des domaines éphémères ; limiter les sorties à des destinations attendues (PS addons, PSP, SMTP, ERP/WMS) réduit l’impact. Même sans refonte réseau, vous pouvez déjà appliquer une politique “deny by default” sur l’hôte (ou au niveau firewall de votre cloud) pour les serveurs applicatifs, et n’autoriser que :
- 443 vers PSP / services métier connus,
- 25/587 vers SMTP (si nécessaire),
- DNS vers votre résolveur interne,
- blocage des connexions sortantes vers Internet “générique”.
Enfin, évitez l’erreur classique : désinstaller des modules ou “nettoyer” à chaud avant de capturer un état. Vous perdez les artefacts (webshell, timestamps) et vous rendez l’analyse incertaine. Même logique pour les actions “cosmétiques” (vider des caches, régénérer des assets, recompiler) : faites-le après snapshot et collecte minimale.
Acquisition de preuves et triage : timeline, IOCs, persistance (sans fantasmes)
Une fois l’hémorragie stoppée, vous passez en mode preuve. Objectif : capturer un snapshot cohérent (VM snapshot, LVM/ZFS snapshot, ou au minimum un tar des répertoires applicatifs + dump DB) avant toute éradication. Sur Linux, préférez des copies qui conservent les attributs :
# Exemple : archive du code applicatif avec métadonnées
cd /var/www
sudo tar --xattrs --acls -cpf /root/forensic_www_$(date +%F_%H%M).tar prestashop/
# Dump DB (attention aux credentials et à la taille)
mysqldump --single-transaction --routines --triggers -u root -p prestashop > /root/forensic_db_$(date +%F_%H%M).sql
Bon réflexe supplémentaire : exportez aussi la configuration runtime (sans secrets si vous devez partager le bundle) :
- conf Nginx/Apache du vhost,
- conf PHP-FPM,
- crontab système,
- liste des paquets et services (utile pour identifier un binaire “ajouté”).
Le triage PrestaShop doit être orienté “IOCs réalistes” : fichiers récemment modifiés, code obfusqué, backdoors PHP dans des chemins inattendus, surcharge via overrides, et JS injecté. Exemples de requêtes utiles :
# Fichiers modifiés dans les 7 derniers jours
find /var/www/prestashop -type f -mtime -7 -print
# Signatures fréquentes d’obfuscation (à interpréter, faux positifs possibles)
grep -R "base64_decode\|gzinflate\|eval(\|shell_exec\|passthru\|system(" -n /var/www/prestashop
# Repérer des scripts PHP planqués dans des assets
find /var/www/prestashop -type f \( -name "*.js" -o -name "*.css" -o -name "*.jpg" -o -name "*.png" \) -exec grep -l "<?php" {} +
Ajoutez un triage “métier PrestaShop” côté base, car beaucoup d’attaques laissent une trace fonctionnelle (compte BO, module installé, configuration modifiée). Exemples de questions à poser à la DB (les noms exacts de tables peuvent varier selon version/préfixe) :
- Employés (BO) : y a-t-il un compte créé récemment ? un email inconnu ? un compte réactivé ?
- Modules : y a-t-il un module activé récemment, surtout s’il n’est pas censé être présent ?
- Configuration : un changement sur l’URL de la boutique, les endpoints, ou des paramètres “mail” (exfiltration par emails) ?
Même si vous n’automatisez pas, le fait d’avoir ces points dans le runbook accélère énormément la qualification.
Côté persistance, ne vous limitez pas au webroot : cherchez cron système (/etc/cron*), crons applicatifs, services systemd ajoutés, clés SSH, comptes UNIX, et modifications Nginx/Apache. Sur PrestaShop, un indicateur récurrent est la création d’un employé BO, ou l’activation d’un module “outil” (souvent déguisé) qui ouvre un endpoint. Recoupez avec les logs d’accès : URIs sur index.php?controller=..., appels POST anormaux, upload de fichiers, hits sur /modules/<module>/... non attendus.
Astuce pratique pour accélérer la timeline : partez de l’heure du premier symptôme (ex. premier client, première alerte 5xx, première transaction suspecte), puis remontez dans les logs reverse proxy pour identifier :
- le premier POST anormal,
- l’IP source,
- le user-agent,
- le pattern d’URI (souvent répétitif), et comparez avec la date de modification des fichiers (mtime/ctime) autour de cette fenêtre. L’objectif est de converger vers un point d’entrée probable et une période d’exposition.
Pour cadrer les tactiques/techniques, MITRE ATT&CK est un référentiel utile pour structurer le rapport (https://attack.mitre.org/), mais gardez l’approche pragmatique : l’objectif est de confirmer le vecteur et l’ampleur, pas de produire un roman.
Éradication et remise en service : reconstruire proprement (souvent mieux que “nettoyer”)
Sur PrestaShop, l’éradication “à la main” est rarement fiable si vous suspectez une compromission serveur : trop de surface (modules, overrides, thèmes, fichiers uploadés, caches) et pas de contrôle d’intégrité natif. La stratégie la moins mauvaise est souvent : rebuild depuis une source saine (tag officiel, artefact CI) + restauration sélective des données (DB, médias) après inspection. Si vous avez déjà une discipline de déploiement, c’est un cas d’usage naturel du blue/green : provisionner un environnement “green” propre, y déployer le code validé, puis basculer le trafic après tests (voir Migration PrestaShop : audit technique et plan incrémental blue/green).
Concrètement, “rebuild propre” = vous évitez de transporter l’infection :
- Code : redéployé depuis source/artefact connu (core + thème + modules) et comparé (hash/manifest CI).
- Médias (
img/,upload/) : restaurés après scan (au minimum : recherche de.php, double extensions, fichiers récemment modifiés). - Base : restaurée si vous avez un backup antérieur à l’intrusion ; sinon, assainissement ciblé (suppression comptes BO inconnus, rotation tokens, audit des configs).
La remise en service doit inclure un contrôle explicite des composants à haut risque : modules paiement, overrides, templates du checkout, scripts front, endpoints API, et accès BO. Si votre incident touche le checkout (skimmer), vous refaites un audit de flux : CSP/headers, intégrité des scripts chargés, endpoints PSP, et tests de paiement en sandbox si disponible (cf. les implications PCI-DSS et tests côté paiement ; à rapprocher de vos pratiques de tests, même si le sujet est adjacent à Paiement en plusieurs fois PrestaShop : tests sandbox, TAEG et conformité PCI-DSS).
Pour les erreurs applicatives post-restauration, appuyez-vous sur une méthodologie de logs/503 (voir Erreur HTTP 503 : diagnostic serveur, logs et ressources et, côté impacts SEO si vous avez des pages qui “blanchissent” sous charge, Page vide : causes fréquentes et impact sur l’indexation Google). C’est aussi un point business : une remise en ligne “instable” multiplie les risques (clients perdus, cache incohérent, paniers cassés) et rend la détection d’une persistance plus difficile.
Enfin, validez la récupération avec des critères mesurables : (1) aucun compte BO inconnu, (2) comparaison de hash entre code déployé et source CI, (3) absence de connexions sortantes anormales, (4) WAF en “monitoring” puis “blocking” sur les règles pertinentes, (5) stabilité des métriques applicatives (taux 5xx, latence, erreurs JS). Tant que vous ne savez pas expliquer le vecteur initial, vous considérez l’incident comme non clos : vous avez remis en ligne, pas “résolu”.
Post-incident : durcissement ciblé, contrôle d’accès, et obligations (RGPD/PCI)
Le durcissement post-incident utile n’est pas une checklist générique, c’est la réduction de la surface réellement exploitée. Si le vecteur est un contrôle d’accès faible (IDOR, privilèges BO, endpoints module), formalisez des barrières côté code et côté infra. Votre article Broken access control : prévenir IDOR et élévation de privilèges est un bon socle : sur PrestaShop, l’empilement contrôleurs legacy + modules + overrides crée des angles morts, et l’absence de tests d’autorisation systématiques dans des modules tiers est un pattern récurrent.
Côté “hardening rapide”, privilégiez ce qui bloque des classes entières d’attaque : mises à jour core/modules, permissions filesystem strictes, désactivation de fonctions PHP à risque si compatible, limitation d’upload, et headers de sécurité. Pour cadrer proprement CSP/HSTS/XFO, voir HTTP Security Headers en PHP : guide CSP, HSTS, X-Frame-Options ; attention, une CSP trop agressive peut casser des modules front (notamment checkout) : testez en report-only d’abord. Pour l’hygiène serveur et sauvegardes chiffrées, rattachez ça à votre stratégie de maintenance : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées. Et pour tout ce qui touche clés/tokens d’API, appliquez des limites de débit et des rotations documentées (voir API : sécuriser apikey, limiter le débit et renforcer la conformité).
Deux actions post-incident à fort ROI (souvent oubliées) :
- Réduire la capacité de modification “invisible” : exiger que tout changement (module, override, thème) passe par CI/artefact, et bloquer l’écriture sur le code en production (permissions + user de déploiement). Cela complique beaucoup la ré-infection.
- Durcir le Back-Office : accès via VPN/bastion, allowlist IP, suppression des comptes prestataires dormants, et revue des permissions employés. Sur PrestaShop, un BO exposé est un multiplicateur d’incident.
Sur les obligations, arrêtez les approximations : si données personnelles potentiellement compromises, le RGPD impose une fenêtre stricte. Le texte est explicite : “The controller shall notify the personal data breach to the supervisory authority … not later than 72 hours after having become aware of it.” (RGPD, Article 33, https://eur-lex.europa.eu/eli/reg/2016/679/oj). En pratique, votre plan de réponse à incident PrestaShop doit inclure : critères de qualification “violation de données”, collecte des éléments minimaux (nature des données, volume, mesures prises), et canal de notification.
Pour une boutique basée en France, l’autorité de contrôle est la CNIL ; avoir le lien et le processus dans le runbook évite de perdre des heures en pleine crise : https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles (CNIL, page de notification des violations de données).
Si vous traitez des paiements, votre IR doit aussi s’aligner sur les exigences contractuelles/acquéreur/PSP et sur les standards PCI (documentation PCI SSC : https://www.pcisecuritystandards.org/document_library). Point important côté PCI DSS : au-delà de la technique, vos partenaires paiement peuvent exiger des actions et délais spécifiques (conservation des preuves, enquête, communication). Ce volet doit être préparé à l’avance (contacts PSP/acquéreur, procédure interne, personnes habilitées).
Le point clé : un containment immédiat propre (coupure checkout + rotation secrets + preuves) réduit drastiquement le périmètre de notification et les coûts — et vous évite surtout de devoir répondre, a posteriori, à la question la plus difficile : “qu’est-ce qui a pu être exposé, exactement, et pendant combien de temps ?”