Comment corriger une faille PrestaShop et éviter une nouvelle intrusion ?

Une faille PrestaShop ne se corrige pas en installant simplement une mise à jour. Si un attaquant a déjà exploité une vulnérabilité, il peut avoir ajouté un fichier PHP, créé un compte employé, modifié un module ou récupéré des identifiants. La priorité est donc de contenir l’incident, d’identifier le point d’entrée, de restaurer un état fiable, puis de supprimer les causes qui permettraient une nouvelle intrusion. Cette méthode s’applique aussi bien à une alerte de sécurité connue qu’à des symptômes tels que des redirections, des commandes suspectes, des e-mails inconnus envoyés par la boutique ou des fichiers modifiés sans intervention.

1. Contenir l’incident sans détruire les preuves

Évitez de modifier ou supprimer des fichiers au hasard dès la découverte du problème. Vous risqueriez de rendre l’analyse impossible et de supprimer des éléments nécessaires à la restauration. Commencez par limiter l’accès public à la boutique.

• Activez le mode maintenance depuis le back-office si vous y avez encore accès. Dans les versions récentes, ce réglage se trouve généralement dans les paramètres de la boutique, section maintenance.
• Si le back-office est inaccessible, demandez à l’hébergeur de restreindre temporairement l’accès au site ou protégez l’accès par authentification HTTP. Conservez votre adresse IP autorisée pour pouvoir intervenir.
• Sauvegardez immédiatement les fichiers du site, la base de données et les journaux disponibles avant toute correction. Il s’agit d’une copie d’investigation, pas nécessairement d’une sauvegarde saine à restaurer.
• Prévenez votre prestataire de paiement si vous suspectez une modification du tunnel de commande, un script inconnu sur les pages de paiement ou une fuite de données clients.

Le mode maintenance limite les dégâts, mais ne neutralise pas un accès serveur déjà compromis. Un pirate ayant obtenu des identifiants FTP, SSH, d’hébergement ou de base de données peut continuer à agir. Il faut donc traiter l’infrastructure en même temps que PrestaShop.

2. Identifier le vecteur d’entrée probable

Une correction durable dépend de la cause. Vérifiez d’abord la version exacte du cœur PrestaShop, celle de PHP, les modules installés et les derniers changements réalisés. Comparez ces informations aux avis de sécurité publiés par PrestaShop et par les éditeurs de modules. Une vulnérabilité connue dans un module désactivé peut rester exploitable si ses fichiers sont toujours accessibles : désinstaller ou supprimer proprement le module est parfois nécessaire.

Contrôler les journaux utiles

Consultez les journaux d’accès et d’erreurs PHP de l’hébergement sur la période précédant l’incident. Recherchez notamment les requêtes vers des fichiers récemment ajoutés, des appels répétés à des scripts d’administration, des téléversements inhabituels ou des erreurs liées à un module. Dans le back-office, examinez également les comptes employés, leurs profils, leurs dernières connexions et les modules installés récemment.

Une date de modification récente n’est pas une preuve absolue : une mise à jour légitime modifie aussi des fichiers. En revanche, un fichier PHP au nom aléatoire dans un dossier d’images, de cache, de téléchargement ou d’upload mérite une vérification immédiate. Les fichiers destinés aux images ne devraient pas exécuter de code PHP.

Rechercher les mécanismes de persistance

Les intrusions ne se limitent pas au fichier initial. Contrôlez les tâches planifiées du compte d’hébergement, les règles de redirection, les utilisateurs FTP ou SSH, les clés de déploiement et les scripts exécutés par cron. Côté PrestaShop, vérifiez les overrides, les modules, les comptes employés et les contenus injectés dans les réglages ou les pages CMS. Un code malveillant peut aussi être inséré dans un fichier JavaScript du thème afin de charger un script externe.

3. Restaurer une base saine plutôt que nettoyer à l’aveugle

La solution la plus fiable consiste à repartir d’une sauvegarde antérieure à l’intrusion, puis à réappliquer les correctifs nécessaires. Une sauvegarde n’est utilisable que si vous connaissez sa date, son intégrité et si elle précède le premier signe d’activité suspecte. Restaurer une sauvegarde postérieure à l’attaque peut réintroduire la porte dérobée.

1. Créez un environnement de préproduction ou une copie locale de la boutique afin de valider la restauration sans remettre immédiatement le site en ligne.
2. Remplacez les fichiers du cœur PrestaShop par une distribution officielle correspondant à la version cible, en suivant la procédure de mise à jour adaptée à votre version.
3. Réinstallez les modules et le thème depuis leurs sources officielles ou depuis des archives vérifiées. Ne recopiez pas automatiquement tous les fichiers de l’ancienne installation.
4. Restaurez la base de données depuis une sauvegarde saine, puis contrôlez les comptes employés, les paramètres de paiement, les transporteurs et les contenus éditoriaux.
5. Appliquez les mises à jour de sécurité du cœur, des modules et du thème avant de rouvrir la boutique.

Une mise à jour majeure de PrestaShop doit être préparée : vérifiez la compatibilité de PHP, du thème, des modules critiques et de votre solution de paiement. Sur une boutique compromise, lancez cette opération après nettoyage et validation, pas directement sur la production endommagée.

4. Révoquer tous les accès potentiellement exposés

Après une intrusion, considérez les secrets utilisés par la boutique comme potentiellement compromis. Changez les mots de passe depuis un poste fiable et privilégiez des mots de passe uniques, longs et stockés dans un gestionnaire.

• Réinitialisez les accès au back-office PrestaShop pour tous les employés, puis supprimez les comptes inconnus et désactivez les comptes inutilisés.
• Modifiez les accès à l’hébergement, FTP ou SFTP, SSH, panneau d’administration, base de données et boîtes e-mail associées au domaine.
• Révoquez et recréez les clés API, jetons de webservice et identifiants de services externes utilisés par les modules.
• Contrôlez les droits des employés : un compte chargé des commandes n’a pas forcément besoin d’installer des modules ou de modifier la configuration technique.

Ne modifiez pas au hasard les clés internes de chiffrement ou de session présentes dans la configuration PrestaShop. Leur rotation peut invalider des sessions ou affecter des données selon la version et les modules. Préparez cette action, documentez-la et testez-la d’abord sur une copie de la boutique.

5. Fermer les failles techniques les plus fréquentes

Maintenir un inventaire des composants

Listez le cœur PrestaShop, le thème, chaque module, son éditeur, sa version, sa date de dernière mise à jour et son utilité. Désinstallez les modules non utilisés plutôt que de les laisser désactivés. Évitez les modules téléchargés depuis des sources non officielles, les versions modifiées sans suivi et les extensions abandonnées sans correctif de sécurité.

Durcir l’hébergement

Utilisez une version de PHP encore maintenue et compatible avec votre version de PrestaShop. Désactivez l’exécution de PHP dans les répertoires d’upload lorsque l’hébergement le permet, sans bloquer les fonctions nécessaires à la boutique. Vérifiez les permissions : les répertoires d’écriture doivent être limités aux seuls dossiers qui en ont besoin ; évitez les permissions trop ouvertes comme 777. Activez HTTPS sur tout le site et forcez les redirections vers l’URL canonique.

Protégez le back-office avec une URL d’administration non évidente, des mots de passe robustes et, si votre contexte le permet, une restriction d’accès par IP ou une authentification supplémentaire. Une restriction IP est particulièrement pertinente pour une équipe qui travaille depuis des adresses fixes, mais elle doit prévoir une procédure de secours pour les accès mobiles ou les prestataires.

Surveiller les changements anormaux

Planifiez des sauvegardes automatisées des fichiers et de la base de données, avec conservation de plusieurs points de restauration hors de l’hébergement principal. Testez réellement la restauration : une sauvegarde inutilisable ne protège pas une boutique. Ajoutez une surveillance des modifications de fichiers, des erreurs serveur et des connexions au back-office. Enfin, définissez une procédure d’incident indiquant qui isole le site, qui contacte l’hébergeur, où se trouvent les sauvegardes et comment valider le retour en ligne.

6. Vérifier la boutique avant sa remise en ligne

Avant de désactiver le mode maintenance, testez le parcours complet sur une copie ou avec une commande de test : affichage des pages, connexion client, ajout au panier, création de compte, paiement, e-mails transactionnels, génération de facture et accès au back-office. Contrôlez aussi le code source des pages sensibles pour repérer un script externe non identifié, en particulier sur le panier et le paiement.

Conservez une chronologie de l’incident : heure de détection, fichiers et comptes concernés, sauvegarde utilisée, correctifs appliqués et mots de passe révoqués. Ce document évite de répéter les mêmes vérifications lors d’un incident ultérieur et facilite les échanges avec l’hébergeur, le prestataire de paiement ou votre responsable de traitement des données.