Sécurité PrestaShop : failles (CVE), signes de piratage et que faire

La plupart des piratages de boutiques ne commencent pas par une attaque sophistiquée du cœur, mais par un vieux module avec une faille connue. La sécurité PrestaShop repose sur quelques règles simples : cœur, modules et PHP à jour, vérification des modules installés face aux vulnérabilités connues (CVE), comptes séparés et mots de passe solides dans le back-office, droits des fichiers corrects et sauvegardes régulières. Voici où vérifier les failles, comment savoir si votre boutique a été piratée et que faire, étape par étape, après une attaque.

Comment les boutiques PrestaShop se font-elles pirater ?

Données clients et paiements transitent par une boutique, et beaucoup tournent des années sans mise à jour. Les portes d'entrée les plus fréquentes :

• Des modules tiers vulnérables. Le plus souvent une injection SQL dans un contrôleur ou un script AJAX du module, appelable sans être connecté. L'attaquant lit alors la base ou y écrit son propre code.
• Un cœur PrestaShop obsolète. Les failles du cœur sont plus rares, mais scannées automatiquement. En juillet 2022, PrestaShop a publié la version 1.7.8.7 pour corriger la CVE-2022-36408, utilisée pour injecter de faux formulaires de paiement dans de nombreuses boutiques.
• Des mots de passe faibles ou volés pour le back-office, le FTP, le SSH ou le panneau d'hébergement.
• Des restes : dossier d'installation, sauvegardes de la base dans le dossier public, anciens scripts d'import, modules désinstallés dont les fichiers sont toujours sur le serveur.

Un point méconnu : désactiver ou désinstaller un module ne supprime pas ses fichiers, et un script PHP autonome vulnérable reste appelable depuis un navigateur. Supprimez du disque les modules inutilisés.

Failles PrestaShop (CVE) : où les vérifier ?

Les vulnérabilités connues reçoivent un numéro CVE et sont publiées à plusieurs endroits :

• Friends of Presta tient une liste publique d'alertes de sécurité, surtout pour les modules : security.friendsofpresta.org. Chaque alerte indique le module, les versions touchées, la version corrigée (s'il y en a une) et le numéro CVE.
• PrestaShop publie les alertes concernant le cœur dans le dépôt du projet : github.com/PrestaShop/PrestaShop/security/advisories.

Pour vérifier votre boutique :

1. Dans Modules → Gestionnaire de modules, relevez les modules installés et leurs versions, y compris les modules désactivés.
2. Comparez cette liste avec les alertes de Friends of Presta, en cherchant par nom technique (nom du dossier dans /modules), pas par nom commercial.
3. Pour les modules vulnérables, installez la version corrigée. S'il n'y a pas de correctif ou si l'auteur a disparu, il faut supprimer le module, le remplacer ou le corriger vous-même.
4. Vérifiez la version du cœur dans Paramètres avancés → Informations et comparez-la avec les alertes PrestaShop.

Les modules au code obfusqué (encodé) posent un problème à part : impossible de les relire sérieusement, ni vous ni un auditeur ne voyez ce qu'ils font ou s'ils cachent une faille. Nos modules sont livrés avec un code lisible, sans DRM ni obfuscation, que tout développeur peut contrôler.

Comment mettre à jour PrestaShop en toute sécurité ?

Les mises à jour sont la protection la moins chère, et la plus souvent repoussée :

• Le cœur PrestaShop. PrestaShop 1.6 ne reçoit plus de correctifs depuis des années, et l'écart entre la 1.7 et les versions 8 et 9 est important. Si vous restez en 1.7, installez au moins la dernière version de cette branche. Nous détaillons le passage dans Comment mettre à jour PrestaShop, et si vous préférez le confier, nous proposons une mise à jour PrestaShop à prix fixe.
• Modules et thème. Surveillez les mises à jour, surtout des modules qui reçoivent des données des visiteurs (paiement, formulaires, export).
• PHP et serveur. PHP 7.4 et 8.0 ne reçoivent plus de correctifs de sécurité. Les versions de PHP et de la base de données figurent aussi dans Paramètres avancés → Informations.

Avant chaque mise à jour, sauvegardez fichiers et base de données et testez sur une copie de la boutique.

Back-office et comptes employés

• Nom du dossier d'administration. L'installateur lui donne en général un nom aléatoire. Ne le renommez pas en admin, panel ou au nom de la boutique.
• Pas de dossier install. Ni lui ni les anciennes archives ZIP de la boutique ne doivent rester sur le serveur.
• Des comptes séparés. Chaque personne a son compte dans Paramètres avancés → Équipe → Employés, avec un profil et des droits limités au nécessaire. Désactivez sans attendre le compte d'une agence ou d'un ancien salarié.
• Des mots de passe solides et uniques, avec un gestionnaire de mots de passe. Dans PrestaShop 8 et 9, la politique de mot de passe se règle dans Paramètres avancés → Sécurité, et Sessions employés affiche les sessions actives pour supprimer celles qui sont suspectes.
• Une barrière de plus. L'hébergeur peut limiter le dossier d'administration à certaines IP ou ajouter un second mot de passe côté serveur.
• Clés API. Dans Paramètres avancés → Webservice, supprimez les clés inutilisées et ne laissez aux autres que les droits nécessaires.
• La protection des jetons dans le back-office doit rester activée.

Droits des fichiers et configuration du serveur

Les réglages sûrs habituels sont 755 pour les dossiers et 644 pour les fichiers, jamais 777. Les fichiers de configuration contenant le mot de passe de la base (app/config/parameters.php depuis PrestaShop 1.7) ne doivent être lisibles que par l'utilisateur sous lequel tourne la boutique.

PrestaShop fournit des fichiers .htaccess qui, entre autres, bloquent dans le dossier img l'accès à tout ce qui n'est pas une image. Ils ne fonctionnent toutefois que sous Apache. Sous nginx, l'administrateur du serveur doit ajouter des règles équivalentes, sinon un fichier PHP déposé via une faille dans le dossier des images sera exécuté.

En production, désactivez le mode debug, le listage des dossiers et l'affichage des erreurs PHP, et gardez les sauvegardes hors du dossier public.

Comment savoir si votre boutique PrestaShop a été piratée ?

Signes typiques d'un piratage :

• Un skimmer de paiement. Un faux formulaire de carte apparaît au paiement, ou un script se charge depuis un domaine inconnu. Souvent, ce sont des clients victimes de fraude à la carte qui donnent l'alerte.
• Des employés inconnus dans Paramètres avancés → Équipe → Employés, ou des adresses e-mail modifiées sur des comptes existants.
• Des fichiers modifiés. Nouveaux fichiers PHP dans img, upload, modules ou le dossier du thème, index.php modifié, fichiers remplis de longues chaînes base64_decode et eval.
• Du spam. Envois d'e-mails en masse, pages aux mots-clés étrangers dans Google, visiteurs venant des moteurs redirigés ailleurs.
• Des alertes externes. Un avis de problème de sécurité dans Google Search Console, un blocage par votre prestataire de paiement ou votre hébergeur.
• Une charge serveur soudaine et des entrées suspectes dans Paramètres avancés → Logs.

Contrôle rapide du cœur : dans Paramètres avancés → Informations, la section Liste des fichiers modifiés compare les fichiers PrestaShop avec les originaux de votre version. Elle ne couvre ni les modules tiers ni le thème, mais révèle vite les fichiers du cœur altérés.

Que faire après le piratage de votre boutique PrestaShop ?

Procédez dans l'ordre : supprimer des fichiers dans la précipitation efface les traces de l'intrusion.

1. Limitez les dégâts. Activez la maintenance dans Paramètres de la boutique → Paramètres généraux → Maintenance, ou désactivez le moyen de paiement concerné.
2. Conservez les preuves. Copiez les fichiers, la base et les logs du serveur en l'état, avant toute modification.
3. Changez tous les mots de passe et clés : comptes employés, base de données, FTP et SSH, panneau d'hébergement, clés API de la boutique et clés des prestataires de paiement. Supprimez les comptes inconnus.
4. Trouvez la porte d'entrée. Examinez les logs d'accès, comparez les fichiers avec des copies propres de la même version et vérifiez les modules face aux alertes.
5. Nettoyez ou restaurez. Si vous avez une sauvegarde propre antérieure à l'infection, restaurez-la puis ressaisissez les commandes manquantes. Sans correction de la faille, l'attaque se répétera vite.
6. Corrigez et mettez à jour. Supprimez les modules vulnérables et inutilisés, mettez à jour le cœur, les modules et PHP.
7. Prévenez votre prestataire de paiement et votre hébergeur. Pour savoir si vous devez déclarer une violation de données personnelles, consultez un juriste ou votre délégué à la protection des données.
8. Surveillez fichiers, comptes et logs pendant les semaines suivantes, et demandez un réexamen dans Google Search Console.

Si la boutique affiche une page blanche ou une erreur 500 après le nettoyage, consultez Page blanche et erreur 500 dans PrestaShop. Pour l'avenir, mettez en place des sauvegardes automatiques des fichiers et de la base, stockées hors du serveur de la boutique.

Comment assurer la sécurité PrestaShop au quotidien ?

Si vous manquez de temps, confiez-nous un audit et correction de la sécurité de la boutique.

Questions fréquentes

Vous soupçonnez un piratage ou voulez vérifier votre boutique avant qu'il ne soit trop tard ? Contactez-nous, nous vous dirons par où commencer.

Produits de cet article

Audit et correction de la sécurité de la boutique

1 499,00 €

Note sur 5 étoiles d'après () avis

Ajouter au panier

Retour : Blog