Audit de sécurité d'une boutique PrestaShop : quoi vérifier et dans quel ordre

Il y a deux moments pour auditer une boutique : quand vous soupçonnez que quelque chose ne va pas et quand tout semble aller bien. Le premier est urgent ; le second est celui qui évite le premier. Dans les deux cas, la liste est la même, et l'ordre compte : d'abord ce qui permet d'entrer et de rester, ensuite ce qui permet d'encaisser, et enfin ce qui permet de se rétablir.

Il ne s'agit pas d'une liste de bonnes pratiques de configuration, mais de vérifications concrètes : quoi ouvrir, quoi chercher et ce que signifie ce que vous trouvez.

Avant de commencer : ne détruisez pas les preuves

Si l'audit fait suite à un soupçon, faites d'abord une copie complète des fichiers et de la base de données en l'état, et travaillez dessus chaque fois que possible. En cas d'infection, vous aurez besoin de savoir depuis quand et ce qu'elle a touché, et cela se perd au nettoyage.

Autre règle : ne validez rien pendant la vérification. Si votre outil de surveillance crée une référence d'« état normal », ne la créez pas avant d'avoir terminé. Une référence établie sur une boutique compromise considère l'infection comme saine pour toujours.

1. Les employés

• Listez tous les employés et leurs profils. Reconnaissez-vous tous les SuperAdmins ?
• Cherchez des comptes aux identifiants consécutifs en fin de liste, des adresses e-mail extérieures ou des noms vides : c'est la trace typique d'une injection SQL.
• Vérifiez les comptes des personnes qui ne travaillent plus avec vous, d'anciennes agences et de tests. Un compte inactif oublié est une porte.
• Vérifiez que tous ceux qui doivent l'avoir ont activé la double authentification.

2. Les comptes webservice

C'est la porte dont personne ne se souvient. Vérifiez dans Paramètres avancés → Webservice :

• Combien de clés il y a, à quoi sert chacune et si l'une d'elles n'a pas de description.
• Quels droits elles ont. Un droit d'écriture sur la configuration ou un droit quelconque sur les employés représente beaucoup de pouvoir.
• Si le webservice est actif sans HTTPS forcé, la clé circule en clair.

Ne désactivez pas une clé « au cas où » sans savoir ce que c'est : il s'agit souvent de l'intégration de l'ERP ou d'une marketplace.

3. Les modules

• Listez les modules installés avec leur version et comparez-la avec la dernière publiée par leur auteur.
• Cherchez ceux qui font l'objet d'avis de sécurité publiés et ceux qui sont abandonnés.
• Cherchez dans modules/ les dossiers sans module enregistré : les orphelins.
• Méfiez-vous des modules sans auteur identifiable, aux compatibilités impossibles ou aux descriptions qui n'expliquent rien.
• Examinez override/ : chaque fichier qui s'y trouve modifie le cœur.

4. Les fichiers modifiés

La vérification la plus précieuse ne dépend de la reconnaissance d'aucun motif :

• Comparez le cœur avec le ZIP officiel de votre version exacte, vendor/ compris. Un fichier du cœur ne devrait jamais changer, sauf lors d'une mise à jour.
• Comparez chaque module avec son paquet d'origine. Ce qui n'était pas dans le paquet, quelqu'un l'a ajouté.
• Cherchez du PHP là où il ne doit pas y en avoir : upload/, download/, img/, des images contenant du code.
• Cherchez des fichiers JavaScript aux lignes disproportionnées collées au début ou à la fin.
• Méfiez-vous des dates, qui peuvent être falsifiées. Ce qui compte, c'est le contenu.

5. Les templates et la configuration des paiements

C'est là que l'attaquant encaisse, ce point mérite donc d'être traité à part :

• Examinez les templates du checkout de tous les thèmes installés, pas seulement du thème actif, à la recherche de balises <script> que vous ne reconnaissez pas.
• Vérifiez les données de chaque moyen de paiement : l'IBAN du virement, les clés des passerelles, les comptes PayPal.
• Examinez les modules qui permettent d'insérer du HTML ou du code dans l'en-tête ou le pied de page.
• Comparez les commandes payées des dernières semaines avec ce qui est arrivé à la banque ou à la passerelle.

6. La configuration de la boutique

• Les URL de la boutique (domaine et chemins) : un changement ici redirige le trafic.
• La configuration de l'e-mail sortant : un SMTP modifié permet de lire ou de détourner les e-mails.
• Le mode debug désactivé en production et le dossier install/ supprimé.
• Le dossier du back-office avec un nom différent de celui par défaut.

7. Les tâches planifiées

Un cron malveillant vit hors de l'arborescence web, donc aucune analyse de fichiers ne le voit. Vérifiez les tâches du panneau d'hébergement et, si vous y avez accès, la crontab du compte. Une ligne qui télécharge quelque chose et le transmet à un shell, qui décode du base64 ou qui exécute du PHP en ligne n'a aucun usage légitime. Vérifiez aussi les clés SSH autorisées du compte.

8. .htaccess et permissions

• Le .htaccess de la racine : cherchez des redirections conditionnées au navigateur ou à la provenance, qui ne touchent que les mobiles ou les visiteurs arrivant d'un moteur de recherche.
• Les .htaccess de upload/, img/, download/ et var/ : qu'ils existent et qu'ils bloquent réellement l'exécution.
• Dans PrestaShop 8 et les versions antérieures, si modules/ permet d'exécuter des .php par URL.
• Qu'il n'y ait pas de dossiers accessibles en écriture à tous ni de fichiers de configuration lisibles par n'importe qui.

9. Les journaux

• Journaux d'accès du serveur web : des requêtes POST vers des fichiers de modules que vous ne connaissez pas, ou de nombreuses requêtes vers un même contrôleur juste avant un changement.
• Journaux FTP et du panneau d'hébergement, qui sont indépendants des journaux web.
• Journaux d'erreurs de PHP et de PrestaShop : une nouvelle erreur dans un fichier dont la version n'a pas changé est un indice.
• Vérifiez qu'aucun journal n'est accessible par URL depuis l'extérieur.

10. Les sauvegardes

• Existent-elles, sont-elles quotidiennes et stockées hors du serveur ?
• Ont-elles déjà été restaurées pour vérifier qu'elles fonctionnent ?
• Reste-t-il d'anciennes copies à la racine du site, téléchargeables par n'importe qui ?
• Jusqu'où remontent-elles ? Si l'infection date de plusieurs mois, il vous faut une copie antérieure.

Et une fois terminé

Avec tout vérifié et nettoyé, c'est le moment : créez la référence d'intégrité, changez les identifiants et laissez la surveillance en place. Et notez ce qui est ressorti sur les versions : si la boutique est sur un PrestaShop ou un PHP hors support, ou a des modules impossibles à mettre à jour, le prochain audit trouvera la même chose. Maintenir la boutique à jour, c'est ce qui rend la vérification suivante rapide.

Comment le résoudre dans PrestaShop

RKR Security Alert automatise une bonne partie de cette liste : il surveille les employés, les modules, la configuration (avec les changements de paiement signalés comme critiques), les URL de la boutique et les comptes webservice ; compare le cœur avec le ZIP officiel ; analyse les fichiers à la recherche de portes dérobées, de web shells et de skimmers ; contrôle le hash des templates de checkout de tous les thèmes ; vérifie les tâches planifiées et le durcissement des dossiers, et effectue 14 vérifications de configuration du serveur. Il s'installe en mode premier audit, sans référence tant que vous n'avez pas marqué le rapport comme vérifié. RKR Sentinel ajoute la surveillance des erreurs et des paiements qui n'aboutissent pas à une commande. Et si vous voulez un audit réalisé par des personnes, avec un forfait d'heures de support Rekire nous le faisons nous-mêmes, nettoyons ce qui apparaît et vous remettons ce qui reste à faire.