Bien souvent quand on pense à la sécurité c’est qu’il est arrivé quelque chose de grave et qu’il est déjà trop tard… Aie oui, vous avez perdu vos données ? Quelqu’un a pris possession de vos accès ? Pensez à anticiper ces risques pour ne pas vous retrouver dans une impasse.
Failles de sécurité sur Prestashop
Concrètement de ce que j’ai pu voir jusqu’à ce jour, Prestashop n’est pas un CMS réellement exposé à des failles de sécurité, contrairement à WordPress où là si vous ne faites pas les mises à jour régulièrement… à coup sûr 6 mois, voir 1 an plus tard vous vous faites pirater. Avec Prestashop c’est différent, vous pouvez avoir une ancienne version Prestashop 1.4 sans aucun problème d’intrusion et ça c’est une très bonne nouvelle… l’outil tient dans la durée sans devoir faire de mise à jour régulières.
Le FTP la zone de hacking n°1
Bien souvent le FTP c’est l’une des zones très sensible, car l’accès n’est pas changé régulièrement. Cela veut dire que l’on peut parfois accéder à votre serveur pendant des années avec le même login et avoir accès aux fichiers sources du Prestashop. Là par contre, j’ai vu des marchands se faire pirater, car l’accès FTP traînait sur un Post-it ou dans des archives de mail échangés de multiples fois avec des tiers… Instaurez une règle de changer régulièrement votre accès FTP et de supprimer les accès inutilisés.
Protéger le backend Prestashop ?
Pour ce point c’est ce que je vais vous montrer tout à l’heure… le but c’est que l’accès au back-office ne reste pas le même en permanence. Cela évite que des petits malins tentent des combinaisons de connexions sur la page de login… ou que parfois même des ex-employés … une fois hors de l’entreprise essaient d’accéder à vos données (oui j’ai déjà vu beaucoup de choses). A travers le tutoriel on verra une méthode dynamique pour changer cet accès régulièrement.
Piraté par un module Prestashop ?
Est-ce que les modules Prestashop peuvent contenir des Spywares ? De mon expérience je n’ai jamais vu ça… Pour éviter les risques, si vous installez des modules gratuits Prestashop prenez-les sur le forum ou sur des sites Prestashop connus de la communauté. Par contre, évitez les modules gratuits sur des sites étrangers, car vous ne savez pas ce que peut faire le module… parfois il peut y avoir une seule ligne de code qui permet de donner accès à vos données à un parfait inconnu. Typiquement j’évite de prendre des modules Prestashop gratuits sur des sites des pays de l’Est ou Russie… même s’ils semblent super.
Etre toujours en mouvement
En fait c’est l’une des clés… le but n’est pas d’être « invulnérable » mais surtout d’être une cible mouvante. Si vous changez régulièrement vos urls d’accès et vos mots de passes, le niveau de sécurité Prestashop fait un bon en avant. Parfois j’ai vu des Prestashop avec 20 comptes employés… et l’e-commerçant me fait la remarque « Ah oui il travaille plus chez nous, il faut l’enlever lui… » Pourtant, cela fait des mois que l’employé n’est plus en interne… A-t-il accédé aux données depuis son domicile ? A-t-il exporté des données ? Finalement, on n’en sait rien… Prenez les mesures nécessaires & anticipez, cela doit faire partie de votre stratégie d’entreprise.
Pour ce tutoriel vous avez à disposition :
- 1 x fichier « security.php » (pour sécuriser la zone admin)
Résumé de la vidéo : Améliorer la sécurité de sa boutique Prestashop
- Avant tout, assurez-vous que vous n’avez pas de tâches planifiées incluant l’url de votre back-office, car le lien de votre back-office va changer automatiquement chaque jour.
- Intégrez le script « security.php » et indiquez dans le code PHP le nom exact du dossier d’administration, ensuite exécutez l’url du script et magie le nom du dossier admin va changer.
- Si le processus fonctionne, il suffit ensuite de mettre une tâche planifiée vers ce script une fois par jour à minuit pour l’actualisation du nom du dossier.
Hello Germain,
On peut générer des noms aléatoires plutôt qu’utiliser des dates, avec un truc de ce style :
Cela évite de pouvoir tricher en connaissant ton astuce et tester des dates dans les URL
Hello,
Merci beaucoup pour la contribution c’est top.
En fait l’inconvénient de l’aléatoire c’est qu’on ne peut pas deviner l’accès du back-office, sans aller voir physiquement le nom du dossier dans le FTP mais clairement alors là oui on monte encore d’un niveau 😉
A bientôt !
Bonjour,
Premièrement merci Germain !
Et deuxièmement je comprends bien la logique du code donné par Cyssoo, mis à part qu’une portion de code ne fonctionne pas…
Dans la fonction :
function genRandomString($length=14)
à la ligne :
for ($p = 0; $p < $length; $p++)
Le ; ne passe pas, je ne m’y connais pas plus que ça mais je n’ai pas trouvé de solution.
Une idée ?
Merci de votre aide
Hello Toyser,
En fait je donnais juste une idée un peu « geek » pour davantage améliorer la bonne idée de Germain.
La fonction de génération d’une chaîne de caractères aléatoire provient de StackOverflow, mais je rejoins tout de même Webbax sur la réponse qu’il m’a faite.
Finalement, si vous maîtrisez l’accès FTP et vérifiez les personnes ayant accès à votre site, vous n’aurez à mon avis aucun besoin d’un code aussi poussé que celui que j’ai suggéré, ni même de celui de Germain, si ce n’est pour votre propre culture personnelle et l’amélioration de vos compétences 🙂
Bonjour,
Juste pour info : Il existe un module Closing Hours v1.0.0 – par PrestaChamps qui fait qqchose dans le meme genre mais pas aléatoire.
Cordialement,
Pierre
Bonjour,
Ah oui très intéressant, je ne connaissais pas ce module Prestashop : https://www.prestachamps.com/en/privacy-and-security-modules/17-closing-hours-prestashop-backoffice-module.html Cela permet d’éviter que les employés se connectent en dehors des heures du bureau (bon concept).
A bientôt !
Bonjour,
Merci pour ce petit script qui parait vraiment sympa (j’adore tes « trucs & Astuces » et les conseils qui accompagnent les vidéos).
Je suis confronté à une « petite » difficulté avec ce script : il fonctionne et en même temps ne fonctionne pas!… lol, je m’explique :
Nous avons eu un piratage pendant les vacances de Noël 2019. Un fichier est apparu à la racine du site, et deux autres au fin fond du module navigation à facette. J’ai viré les fichiers, et ils sont revenus. J’ai changé les mots de passe backoffice, ftp, et BDD Mysql, et les fichiers sont revenus encore une fois. Je les ai viré de nouveau et j’ai désinstallé le module Navigation à facette. Ce fait deux jours et les fichiers ne sont, pour le moment, pas revenus.
Moi qui avait toujours eu une confiance inébranlable en Prestashop, je deviens plus prudent, et c’est pour ça que ce script m’intéresse au plus haut point.
J’en viens donc au fichier.
J’ai le site en double (une version en production, et un autre, fermé, qui me sert à faire tous les essais avant de les appliquer sur le site principal).
Le site test est donc, en permanence en maintenance (je le précise au cas où le mode maintenance puisse avoir une incidence sur le fonctionnement du script de security.php).
Quand j’appelle le fichier security.php avec Chrome, ca fonctionne parfaitement. Le nom se change correctement avec la date du jour. Mais quand je le fais avec firefox, ca ne fonctionne pas (je ne comprends pas en quoi le navigateur pourrait avoir un impact sur le fonctionnement du script?!…)
De plus, j’ai programmé une tâche CRON grâce au module CRON fourni dans Prestashop :
– Lien cible « https://monsite/security.php »
– Fréquence de la tâche « 01:00 », « Tous les jours du mois », « Tous les mois », « Tous les jours de la semaine ».
Et la tâche CRON ne s’exécute jamais. C’est la seule tâche CRON programmée sur la version test du site.
Y’a t’il une manipulation que j’ai mal exécutée? Je n’ai pas essayé d’exécuter le script avec une tâche CRON de l’hébergeur (toutes celles que j’ai essayé auparavant ne fonctionnent jamais chez 1and1 mais fonctionnent avec le module CRON du site principal (envoi de newsletter, actualisation de l’index d’AdvancedSearch, etc.)
Je suis un poil perdu là, parce que ce script me plait beaucoup et il apporterait de la sécurité au presta tout en permettant à mon copain (le propriétaire du site) de retrouver ses petits et ne pas perdre le chemin de l’Admin (et inutile que je lui explique Filezilla, c’est un monstre de film pour lui! lol).
Si quelqu’un a des petits conseil à m’apporter, je suis preneur. (dans les renseignements en dessous de cette fenêtre, je vais donner l’adresse du site principal, mais le site teste est, bien sûr à une autre adresse)
Bonjour,
A vérifier si les fichiers indésirables Prestashop sont concernés par la faille XsamXadoo : https://www.webbax.ch/2020/01/09/corriger-la-faille-de-securite-xsamxadoo-sur-prestashop-ep-92 XsamXadoo
Pour l’exécution du lien il faudrait éventuellement vérifier si sous Firefox vous avez mis le « www » ou sans le « www »… et pour ce qui est de la tâche planifiée essayez de la mettre en place directement sur votre hébergement sans passer par le module Prestashop (vous pouvez demander aussi de l’aide à votre hébergeur à ce sujet).
A bientôt !
Désolé, j’ai oublié de revenir préciser que j’avais trouvé une solution qui fonctionne, et c’est effectivement, celle qui m’est suggérée, à savoir : j’ai mis en place la tâche CRON au niveau de l’hébergeur et elle marche parfaitement quotidiennement. Merci Webbax!
Mais, après vérification, je ne comprends toujours pas pourquoi ca ne fonctionne pas avec le planificateur de tâche de Prestashop! Pas grave, l’important, c’est que la solution aie été trouvée.
Sinon, pour le piratage, et c’est une information qui peut intéresser du monde. C’est en fait notre problème qui a permis à Prestashop d’identifier la faille qui se trouve au niveau de PhpUnit (au moins, ca aura servi à d’autres! lol).
Je suggère, à tout ceux qui ont un Prestashop d’utiliser le plugin dont je vais fournir le lien et qu’on m’a donné sur le Forum de Prestashop. Il s’agit d’un module qui va identifier si le site en place contient les fichier corruptible. Attention, il ne fait que vous liste des fichier à problème, il ne corrige rien, mais les informations qu’il fourni permet de les identifier précisément et de les supprimer manuellement en ftp par exemple.
Le module (pour presta 1.6 ET 1.7, je l’ai fait fonctionner sur les deux script et c’est parfait) est téléchargeable depuis ce lien :
https://soluka.fr/blog/prestashop/prestashop-faille-phpunit-xsamxadoo-bot/
Voilà, j’espère que ca aidera du monde à se protéger un peu plus.
Merci pour le retour.
Concernant la faille de sécurité Prestashop, j’ai proposé aussi ce tutoriel avec un script pour faire le nettoyage : https://www.webbax.ch/2020/01/09/corriger-la-faille-de-securite-xsamxadoo-sur-prestashop-ep-92/
A bientôt !
Ca serait bien d’avoir un plugin qui installe automatiquement une liste de sécurités.
J’avais trouvé, il y a quelques temps, des conseils, à droite et à gauche de petits scripts à insérer dans le htaccess. Mais personne n’a encore pu proposer, un module qui puisse installer toutes les protections basiques complémentaires.
C’est une petit idée pour celle et ceux qui ont les compétences pour le faire
Sur Prestashop Addons, il existe un module pour renforcer la sécurité de la boutique, mais je ne l’ai jamais testé : https://addons.prestashop.com/fr/securite-access/44413-security-pro.html
Bonjour ,
Tout d’abord merci pour tous ces tutos tellement utiles !
Cette méthode de changement d’url fonctionnait parfaitement et du jour au lendemain plus rien sans qu’aucun changement ne soit réalisé …
Une idée ?
Merci beaucoup par avance !