Une faille dans Prestashop ?
A force de passer pas mal de temps dans le code de solution open source telles que Prestashop, on arrive vite à oublier les discours marketing prônant la sécurité, la stabilité et la performance.
D’ailleurs, même Prestashop fait preuve de lucidité en modifiant le pied de page de son site en passant du logiciel e-commerce open source le « plus fiable » en 2012 au « plus utilisé au monde » en 2013.
Ce n’est pas la première fois que je découvre un problème de sécurité dans une solution open source. Cependant, la simplicité de celui-ci et le fait que tout le monde passe devant sans jamais y prêter attention m’ont poussé à en écrire un article.
Pour être sincère, cela fait déjà plusieurs années que j’ai identifié ce problème de sécurité tout en pensant que les développeurs seraient assez responsables pour le « corriger » avant de mettre en ligne leurs sites. Il semblerait que non…
50% des boutiques testées sont impactées
Avant de crier « au loup », je suis allé vérifier si cette vulnérabilité était exploitable. J’ai donc testé l’ensemble des sites web du showcase Prestashop (catégorie FRANCE).
Résultat : 24 sur 48 des boutiques Prestashop testées sont touchées par cette vulnérabilité.
Ce qui est encore plus inquiétant, c’est que les sites testés font partie des références de Prestashop, qui sont pour la plupart, réalisés par des professionnels du web (agences ou freelances). Je n’ose même pas imaginer le pourcentage que j’aurais obtenu si j’avais également testé des boutiques réalisées par les e-commerçant eux-mêmes !
Quelques exemples bien connus
En quoi consiste cette vulnérabilité ?
Certains l’auront déjà compris en voyant les précédentes captures, cette faiblesse de sécurité de Prestashop permet d’afficher l’ensemble des informations de débogage. Concrètement, n’importe qui peut avoir accès à des informations privées comme le répertoire d’installation de Prestashop, la liste des modules chargés ou des informations sensibles sur les produits.
Pour comprendre ce qui ce passe, revenons sur le fonctionnement interne du chargement d’une page.
- Les données issues de la base de données sont chargées dans des objets métiers (Tag, Product, Cart, etc).
- Le contrôleur de la page demandée passe les objets au moteur de template
- Le moteur de template fusionne le thème avec les données récupérées
Pour simplifier le travail des intégrateurs, il existe une console de débogage intégrée à Smarty. Cet outil est indispensable pour connaître la liste des données pouvant être utilisées dans le template. Par contre, cet outil ne devrait jamais se retrouver en production.
Exploiter cette vulnérabilité, un jeu d’enfant
Même si je pense que beaucoup ont déjà compris comment exploiter cette faille, par principe, je ne révélerai pas la méthode dans cet article. Je vous conseille plutôt de lire la suite afin de vérifier si votre site est sécurisé.
Comment protéger sa boutique ?
Prestashop 1.5
Dans prestashop 1.5, cette console n’est pas activée par défaut mais à surement été activé par la personne qui a conçue le thème. Pour protéger sa boutique, il n’y a rien de plus simple. Aucune modification de code n’est nécessaire. Il vous suffit de vous rendre dans votre interface d’administration et de désactiver la console de débogage Smarty.
Paramètres avancés > Performances > Smarty
Si votre configuration de débogage n’est pas positionnée sur « Ne pas ouvrir la console », votre installation comporte un risque.
Prestashop 1.4
(Edit : Merci à Laurent pour cette précision.)
Dans les version précédente de Prestashop, la console smarty est activée par défaut. Si vous n’avez jamais modifiée la configuration de base, votre boutique est vulnérable. Pour corriger cela, vous devez aller modifier le fichier de configuration smarty en modifiant ‘URL’ en ‘NONE’
/config/smarty.config.inc.php
$smarty->debugging_ctrl = ‘NONE’;
« Ne jamais minimiser l’importance d’une faille de sécurité »
Je vois déjà arriver les commentaires dédramatisant l’importance de ce problème. D’un point de vu général, il ne faut jamais minimiser l’importance d’un bug ou d’une faille de sécurité. A titre d’exemple, une « simple » faille XSS peut permettre d’afficher une alerte JavaScript mais peut aussi permettre de rediriger le visiteur sur un site non désiré ou de lui voler sa session.
Dans le cas présent, je vous propose, ci-dessous, quelques exemples parlants. :
Quels sont les risques pour les sites concernés ?
Affichage du prix d’achat de vos produits
En effet, même si cette information n’est jamais affichée (elle est utilisée que dans le BackOffice pour calculer la marge du commerçant), elle fait partie de l’objet Product qui est construit par Prestashop et assigné à la vue produit. Cette information confidentielle peut donc être vue et pourrait être utilisée par vos clients et vos concurrents.
Savoir si d’autres clients ont accès à des prix spécifiques
Que vous fassiez partie d’un groupe de clients privilégiés ou non, la fiche produit charge l’ensemble des tarifs applicables. Il est donc possible pour n’importe quel visiteur de votre boutique d’exploiter cette faille afin de connaître le meilleur prix que vous êtes capable d’accorder à d’autres client. On retrouve ainsi toutes les réductions masquées et prix négociés de votre catalogue.
Voler des accès tiers (Ex : Facebook)
Les informations chargées dans vos pages peuvent contenir des identifiants sensibles. Je n’ai pas pris le risque d’aller vérifier si les informations de paiement pouvaient être concernées mais l’exemple ci-dessous montre que les informations liées à votre compte facebook sont facilement récupérables.
Récupération d’informations techniques sensibles
Sans trop de surprise, nous avons également accès à des informations pouvant compromettre la sécurité de votre installation comme les répertoires d’installation de Prestashop, des listes d’adresses IP (probablement celles ayant un accès spécial durant la maintenance de votre boutique), les modules chargés, les fichiers JavaScript et CSS avant compilation, les chemins vers les fichiers de template, etc.
Récupération de token en tout genre
Comme vous avez pu le voir précédemment sur la capture du Marketplace de Prestashop, des informations comme l’empreinte du mot de passe peuvent être accessibles (à condition d’avoir monté une session). D’autres empreintes (hash) utilisées en tant que token de sécurité sont accessibles publiquement. On peut lister le secure_key, static_token ou token.
Qu’attendre de Prestashop ?
Cette option étant désactivée par défaut dans la dernière version (elle était activée par défaut en 1.4), il est difficile d’imputer ce problème de sécurité à Prestashop. De plus, cette faille n’est pas liée à un bug mais à une mauvaise configuration.
Le but de cet article n’est pas de trouver des coupables mais de faire en sorte que cette solution open source et l’utilisation qui en est faite s’améliorent. Voici des exemples d’évolutions que l’équipe de Prestashop pourrait mettre en place pour prévenir ce problème :
Informer l’administrateur du problème de configuration
C’est un peu contradictoire mais lorsque la console de débogage est activée, Prestashop indique que la configuration smarty est correcte. Il serait bien de mettre un message en rouge comme on peut l’avoir pour des problèmes de configuration du cache.
Imposer l’utilisation d’un mot de passe
Une solution assez simple à mettre en place et qui garantie de ne plus être vulnérable à cette faille serait d’imposer la saisie d’un mot de passe pour lancer le débogue. Par exemple, une simple authentification HTTP pour lancer la console comme cela se fait déjà pour accéder aux webservices de Prestashop.
[Edit] Cette proposition a été implémentée par PrestaEdit. Le code est à disposition sous GitHub. Merci !
Conclusion
Le but de cet article est d’informer tout un chacun sur cette vulnérabilité et de faire prendre conscience que des petites options insignifiantes peuvent être la cause de vol de données pour vos entreprises. En tant que développeurs, soyez toujours attentifs aux problématiques de sécurité. Ayez toujours en tête que ce qui vous simplifie le développement peut aussi être détourné contre vous. Au-delà de Prestashop, ce problème peut se retrouver sur toutes les solutions utilisant Smarty ou des outils comme FirePHP.
Si vous avez des boutiques sous Prestashop (toutes versions confondues), je vous conseille d’aller rapidement vérifier vos paramètres avant qu’une personne mal intentionnée ne le fasse pour vous (si ce n’est pas déjà fait).
N’hésitez pas à passer le message autour de vous. Si vous avez besoin d’aide dans la configuration ou la maintenance de votre Prestashop, n’hésitez pas à contacter notre équipe de développeurs.
Et pour rappel, n’hésitez pas à venir nous voir au salon e-commerce de Paris en Septembre.
Edit : Prestashop vient de publier un article qui regroupe les règles à respecter avant une mise en ligne.
Merci pour l’info (Même si ce n’est pas vraiment une faille, juste un paramétrage.
En revanche, vous devriez mettre une date sur vos articles, ce serait plus pratique pour les visiteurs car on ne sait pas si ceux-ci datent de Mathusalem ou sont récents :-)
Merci pour cette remarque, l’article date d’aujourd’hui (29/07/2013). L’ajout de la date est prévu mais nous n’avons pas encore trouvé le temps :).
En ce qui concerne le terme « Faille de sécurité », nous sommes justement en plein dedans. Je me permets de citer Wikipedia
Effectivement, ce n’est pas une faille liée à un bug mais à un problème de configuration. La finalité, quant à elle, est la même. Un attaquant peut avoir accès à de nombreuses informations comme vous avez pu le voir dans cet article.
Merci pour cette information.
Pour info et pour compléter votre articles , en fonction de la version de Prestashop, la configuration se trouve directement dans :
config/smarty.config.inc.php$smarty->debugging_ctrl = 'NONE';
C’est d’ailleurs plutôt perturbant de voir qu’il existe un paramètre de configuration dans config/config.inc.php
Que l’on peut mettre à false, mais qui n’est pas pris en compte…
/* Smarty */require_once(dirname(__FILE__).'/smarty.config.inc.php');
/* Possible value are true, false, 'URL'
(for 'URL' append SMARTY_DEBUG as a parameter to the url)
default is false for production environment */
define('SMARTY_DEBUG_CONSOLE', false);
pour ma part, je ne savais même pas que l’on avait cette possibilité.
Le site étant l’un de ceux capturés dans cet article (nom commençant par un T), il n’est pas sur prestashop 1.5 mais sur 1.4.4, ce qui montre que la vulnérabilité n’est pas récente.
Le problème est qu’il n’y a pas sur cette version de possibilité de désactiver cette fonction, on va donc demander à l’agence de bien vouloir désactiver en dur…
Merci pour cette remontée intéressante en tout cas !
Merci pour l’info, l’archiduchesse est désormais safe !
A l’époque, lorsque je travaillais pour PrestaShop, j’ai moi même commis cette fonctionnalité.
J’aurai effectivement du être vigilant…
Nous allons immédiatement corriger cela sur Arthus & Co, même si, comme le dit Laurent, sur une 1.4, cela se fait directement dans le code dans le fichier de config.
Merci pour cet article.
Hello,
Sur base de ta proposition, je viens d’effectuer un Pull Request que voici: https://github.com/PrestaShop/PrestaShop/pull/606
Ce sera – comme tu le dis – une petite configuration supplémentaire qui peut avoir son importance, finalement. Et ça ne mange pas de pain, après tout ! ;-)
Merci beaucoup pour cette contribution ! T’es un chef, comme d’hab ^^
Bonjour,
Merci pour cet article très instructif. J’ai une version 1.4.9 de Prestashop et je ne vois l’option dont vous parlé dans le smarty, est-ce normal ? Peut être que notre agence web l’a déjà enlevé?
Merci
Bonjour,
L’article a été mis à jour suite au commentaire de Laurent.
Vous trouverez la réponse pour Prestashop 1.4
Merci
[…] article publié aujourd’hui annonce une faille de sécurité dans Prestashop, mais selon moi, c’est plus un oubli des développeurs de ces sites. J’ai vérifié sur […]
Bonjour Arnaud !
Un grand merci pour cet article très détaillé, on sent qu’il y a du travail ! Vous avez mis le doigt sur un élément très intéressant et pertinent, ce qui nous a permis de communiquer rapidement et de rappeler à nos utilisateurs de faire attention à agir avec prudence en modifiant la configuration « Optimisation Smarty » : http://bit.ly/13rHU8h
J’en profite pour rebondir sur quelques points pour lesquels quelques précisions ne feront pas de mal ;-)
Vous dîtes qu’il y a encore 1800 bugs non-résolus sur PrestaShop 1.5, mais en fait c’est plutôt 459. Le reste, ce sont des feature requests. PrestaShop est fiable en 1.5.4.1, et le sera encore plus en 1.5.5 très bientôt. Pour les fonctionnalités inachevées, nous ne voyons pas tout à fait auxquelles vous faîtes allusion, mais nous sommes preneurs d’infos :-)
Vous parlez de « problèmes de sécurité » au pluriel : si vous en connaissez un autre que celui qui fait l’objet de votre article, je vous encourage vivement à nous en informer, c’est le genre d’urgence à ne pas se garder sous le coude pour un article de blog… Notre vision de la sécurité n’est pas le « discours marketing » que vous semblez penser. PrestaShop investit énormément à ce niveau, je pense aux nombreux audits de sécurité (internes et externes), aux formations et cours en interne, sans oublier que le code de notre logiciel est open-source, donc surveillé par tous. Encore une fois, si vous voyez des problèmes de sécurité, il est crucial de nous les remonter.
Vous expliquez : « Avant de crier « au loup », je suis allé vérifier si cette vulnérabilité était exploitable. » C’est louable, mais on a le sentiment que cet article a un peu comme effet (non voulu, je le sais bien) d’expliquer aux loups le chemin pour entrer dans la bergerie.
Le fait est que vous avez raison, cette configuration doit être évitée coûte que coûte, car quelques données des boutiques qui peuvent être affichées en front par quelqu’un de mal intentionné sont clairement sensibles. Mais ne sont pas sensibles l’email + mot de passe floutés sur l’exemple d’Addons (ce sont ceux du visiteur, donc au final pas si confidentiel que ça) ou les tokens en tout genre (qui sont publics ou propres au compte du visiteur).
Pour finir, vous proposez des évolutions à mettre en place pour vraiment écarter tout risque de mauvaise manipulation de l’utilisateur. L’idée de l’affichage du message « Optimisation Smarty » en rouge et accompagné d’un triangle « Attention ! » quand la console de débogage est activée est excellente ! Nous nous y mettons tout de suite, le feature sera présent dans l’imminente version 1.5.5. L’autre idée, qui est d’imposer l’utilisation d’un mot de passe pour lancer le débogue, se défend aussi tout à fait, j’invite qui veut s’y lancer à commiter un pull request dans la forge !
Encore merci pour votre « trouvaille » et votre analyse, qui méritait absolument que l’on s’y attarde aujourd’hui. Bonne soirée !
Xavier du Tertre
Community Manager
PrestaShop
Bonjour Xavier,
Vous êtes le bienvenu pour commenter et corriger les imperfections.
Pour les amoureux des chiffres : 5 heures de rédaction/test/vérification, 2 heures de sommeil et 1 journée de « Community Management »
Merci pour cette mise au point. J’ai édité mon article pour y faire référence dès sa parution. Dommage que l’inverse n’ai pas eu lieu, je pense que mon article peu en aider plus d’un.
Les commentaires sont fait pour ça.
J’ai obtenu ces chiffres en faisant une recherche des « Issues » de type « Any » en état « Open » sur le Projet « Prestashop 1.5 ». Effectivement, il n’y a pas que des bugs. Je viens de préciser cela dans mon intro.
On voit que vous n’avez jamais utilisé le module d’importation ou les webservices ? D’ailleurs, j’avais prévu d’écrire un article intitulé « Pourquoi ne pas faire confiance aux webservices de Prestashop » mais je n’ai pas encore eu le temps. Je n’ai rien contre vous, le but est de faire quelque chose de constructif. J’ai d’ailleurs récemment patché les webservices pour y ajouter une des fonctionnalités manquantes
Au cas ou vous n’êtes pas au courant, votre équipe a été informée avant la publication de l’article (Rémi G et Damien M). J’ai d’ailleurs contactés les commerçants directement concernés afin qu’ils corrigent avant la publication.
Je pense que le succès de Prestashop tient dans son Marketing. Je ne parle pas forcement de l’équipe actuelle mais de l’histoire de Prestashop. N’hésitez pas à me suivre sur twitter pour être au courant dès qu’il me vient une envie de râler ^^
Je n’ai jamais douté de la bonne volonté des équipes.
On est tous d’accord mais pour être honnête, quand je vois le code de Prestashop, je ne sais même pas par ou commencer. Rien que le fait de gérer la sécurité des répertoires avec un fichier index.php dans chaque dossier, je trouve ça hallucinant.
Vous ne devez pas être très technique. Le but de cet article est de montrer qu’une option que tout le monde connait sans y prêter attention, peut être une faille de sécurité immense. Avec une faille si énorme, pas besoin de montrer le chemin au loup.
Par contre, je pense qu’il faut marquer les consciences. Ce qui est loin d’être le cas de votre article tout à fait corporate.
Je crois que tout le monde est d’accord.
Je crois que vous n’avez pas lu tout mon article. Ce qu’il faut retenir c’est de ne jamais minimiser une faille. La moindre données, même celle qui ne vous parait pas sensible, peut être (dans certains contextes) utilisées contre vous. Ex : En cas de vol de session, l’attaquant peut récupère l’email et le hash.
De plus, vous essayer de minimiser en prenant les exemples les moins problématiques mais vous excluez certaines informations de votre réponse. Il serait intéressant de nous dire ce que vous pensez de l’exposition du secure_key, facebook secret, wholesale_price, etc.
C’est déjà fait : https://github.com/PrestaShop/PrestaShop/pull/606
D’autres propositions consistaient à utiliser une valeur aléatoire au lieu de la constante de débogage smarty. Ou encore, de restreindre l’accès aux adresses IP de maintenance.
Désolé si je vous ai gâché la journée, je n’avais pas non plus prévu de passer la nuit et la journée là dessus mais quand j’ai vu l’ampleur des dégâts, je ne pouvais difficilement aller me coucher.
Prestashop est une bonne application qui a ses imperfections, Prestashop n’est pas magique et nécessite d’avoir des connaissances techniques pour ne pas tomber dans ses différents pièges.
PS : Le seul message de « reproche » que j’ai reçu venait de Prestashop. Toutes les agences et les e-commerçants qui m’ont contacté à la suite de cela étaient ravis !
Très intéressant… merci pour ce retour…
Je vais aller voir la chose de plus près pour voir comment ça se déclenche ;)
A bientôt !
Merci pour cet article très instructif. Je travaille dans une agence web, je vais donc vérifier tout ça :)
Merci Virginie,
Vous allez voir, la vérification est très rapide.
C’est juste un peu plus compliquer a corriger sur Prestashop 1.4 mais rien de très difficile.
A bientôt
Bonjour Arnaud,
Très joli travail, et très belle alerte, c’est ce que j’appelle du professionalisme. Je regrette juste une chose, c’est que pour le moment, ce ne soit que la communauté Francophone qui est alertée de cette « faille » grâce à ton article et à la twitosphère…
Ton article mériterait de se retrouver sur le Blog de PrestaShop avec au moins les traductions espagnoles et anglaises, dans une rubrique « Best Practice » ou sur la Forge :(
Bref plutôt que d’employer un community manager à enfoncer des portes ouvertes, il devrait plutôt l’employer à prévenir le reste de la planète que leur site peut être en DANGER !!!!
Encore merci et BRAVO !!!
Merci Bruno pour cet enthousiasme. Ça fait plaisir de voir que l’article a été utile à bon nombre de personne.
Et je suis d’accord sur le fait que la communication FR et surtout la communication à l’internationale ne soient pas suffisantes.
D’après les retours que j’ai eu (surtout par email), beaucoup de personnes savaient que c’était activé mais personne n’avait conscience des problèmes que ça pouvait poser. Mon article a au moins servi à alerter sur les conséquences.
Par contre, il n’y aurait pas vraiment d’intérêt à ce que j’en fasse une version Anglaise si celle-ci n’est pas relayée et assumée par Prestashop.
Peut-être que je me trompe :)
Bonjour Bruno,
Vous dîtes « plutôt que d’employer un community manager à enfoncer des portes ouvertes, il devrait plutôt l’employer à prévenir le reste de la planète que leur site peut être en DANGER !!!! »
Ce n’est pas très juste, car la toute première chose que nous avons mis en oeuvre, c’est justement de rédiger un article sur notre site, de toute urgence. Et en anglais, également : http://bit.ly/16gK5AX
Ensuite, et seulement ensuite, ai-je pris le temps de mettre une réponse ici.
Bonne journée !
Xavier du Tertre
Community Manager
PrestaShop
Bonjour,
Je viens d’effectuer le controle sur ma boutique en 1.4.9, mais j’avais déjà ca :
…
$smarty->debugging = false;
$smarty->debugging_ctrl = ‘NONE’; /* ‘NONE’ on production */
Du coup c’est OK, je n’ai pas de vulnérabilité ?
Merci pour cette alerte !!!!
Bonjour,
Je viens de vérifier sur votre boutique. Celle-ci est bien configurée.
Vous n’avez donc pas le souci.
N’hésitez pas si vous avez d’autres questions
Super article.
Je vais faire le tour des sites pour checker si elle est présente.
Pour la version de prestashop 1.5.4.1 par défaut cette option est à « Ne pas ouvrir la console », si je ne dis pas de bêtise.
En tout cas, articles et commentaires constructif :)
C’est effectivement bien configuré par défaut dans Prestashop 1.5.
Par contre, la console est très souvent activé par le graphiste/intégrateur qui créé le thème sans être désactivé par la suite.
Salut Xavier,
« PrestaShop investit énormément à ce niveau, je pense aux nombreux audits de sécurité (internes et externes), aux formations et cours en interne »
Je ne doutes pas un instant de la bonne volonté de PrestaShop de protéger chaque ligne de code, c’est d’ailleurs probablement pour ça qu’il y a des cast à presque toutes les lignes, et cela même quand les types sont validés plus haut. Il arrive même parfois de trouver deux cast consécutifs pour une même variable. Tu trouveras quelques exemples de toute beauté ici http://les-casts-de-prestashop.tumblr.com/ qui nous montre le savoir faire indéniable de l’équipe de sécurité. Comme le disait Bruno42 « les casts, tu trouveras ça au début de tout bon bouquin de sécurité ». Il voulait surement parler du célèbre livre pour enfants « Martine hack le grille pain de ses parents ».
PrestaShop est le seul projet open source que je connais qui protège son code avec des casts à outrance, c’est surement une technologie visionnaire – que dis je ! – la péninsule qui bloque les armés des ténèbres de hackers ! D’ailleurs PrestaShop est aussi un logiciel qui promeut l’absence de MVC, de commentaires dans le code, de code objet structuré. PrestaShop est un exemple d’architecture, une œuvre d’art qui aurait même faire pâlir De Vinci s’il avait été développeur.
Remi G. est mon mentor, et depuis qu’il m’a appris à protéger mon code de failles extrêmement énormément totalement critiques qui font peur avec sa célèbre fonction bqSql(), je peux enfin dormir la nuit. MERCI !
Sérieusement sans rire, Xavier t’es expert twitter, pas sécurité il me semble, ça serait bien d’arrêter de proclamer des âneries dans les bergeries :)
Cordialement,
Simple buzz …
C’est une option de configuration, je ne vois pas l’intérêt d’un tel titre pour cette article.
« Prestashop, une faille de sécurité liée à smarty »
Aucune faille de sécurité n’existe, ceci s’appelle simplement une option de configuration au même titre que la configuration du mode DEV.
Nous sommes bien devant une vulnérabilité du système permettant de porter atteinte à la confidentialité des données ?
C’est justement la définition d’un faille de sécurité.
Une faille de sécurité ne signifie pas forcement un bug dans une application. Je suis désolé si ce titre vous à laissé pensé le contraire.
De plus, cette configuration est de base sur l’ensemble des Prestashop en version 1.4 (soit une grande partie des 150.000 Prestashop)
C’est effectivement une erreur de paramétrage entraînant un trou de sécurité sur la confidentialité des données, et non une faille de sécurité Prestashop ou Smarty.
Pour info :
Si chez moi je fais installer une porte blindée mais que j’ai pour habitude de laisser les clés dans la serrure à l’extérieur.
Est-ce une faille de sécurité du fabricant ? ou de l’installateur ?
Bonjour Aideaunet,
J’ai un peu du mal à comprendre la frustration que les personnes techniques ont vis-à-vis du terme « Faille ».
Vous êtes d’accord pour dire que c’est un trou mais pas que c’est une faille, alors que tout cela est synonyme.
Trou, défaillance, déficience, faiblesse, vulnérabilité ou faille de sécurité. Vous pouvez appeler cela comme vous le souhaitez mais ça ne changera pas qu’il y a un GROS problème de sécurité sur de très nombreux sites e-commerce basés sur Prestashop.
EDIT : Au passage, votre site de démo n’est pas protégé… Mais on est d’accord pour dire qu’il n’y a pas de problème ;)
[…] faille de sécurité dans Prestashop Franchement j’avais pas vraiment fait attention, mais Wixiweb a levé le voile sur ce problème, une faille est bien présente… elle est liée au Debug de Smarty. C’est-à-dire […]
Merci pour le patch que j’ai appliqué sur ma boutique en 1.4.8.2 !
Bonjour Arnaud, je tiens à te féliciter pour ton article et surtout à te remercier. Certains minimisent l’énorme problème que ceci peut engendrer pour l’ecommerçant. Tout ce travaille de fond (souvent du ecommerçant) réduit à néant !? C’est tout simplement ne rien comprendre au ecommerçant. Si ceci n’est pas grave, alors toutes ses info. seraient dans les descriptions ou visibles sur le site. On arrive aujourd’hui à une situation où le travail d’équipe devient de plus en plus important. Quelqu’un qui sait tout faire seul magnifiquement bien (dev, marketing, acheteur et vendeur), perso je n’en connais pas. Perso., ce n’est pas une faille mais un gouffre: prix d’achat, fournisseurs, dimensions (où tu as passé des heures pour que tout soit parfait), etc.
Ne serait-il pas plus judicieux pour Presta qu’avec les audits internes et externes faient justement à outrances (ce que je trouve très bien), de faire faire aussi un audit via des champions de Presta comme toi Arnaud, Germain de Webbax et bien d’autres qui maîtrisent parfaitement bien leur sujet (qui sont entre Presta et le ecommerçant) et pourquoi pas avec des ecommerçants petits, moyens et géants et surtout qui ont un oeil décalé. En somme des auditeurs courageux, qui n’ont pas peur de se mouiller et de montrer les faiblesses du système d’un outil qu’ils adorent.
Edgar
Merci, ça fait plaisir de voir que l’article a été compris par certains !
Ça compense avec certaines critiques moins sympathiques que je reçois, m’accusant de dramatiser ou du vouloir faire de la publicité de mauvais goût.
Des commentaires comme le tiens me confirment que j’ai eu raison de prendre un peu de mon temps pour creuser le problème et pour communiquer dessus. Après, il est vrai que ça ne plaît pas à tout le monde, c’est dommage.
Bonjour,
je suis tombé sur votre article un peu par hasard, et je tiens a vous félicité car il est très complet et surtout instructif pour les personnes qui ont eux même mis en place leur prestashop ou voir même pour les agences qui ne seraient pas au courant de ce paramètre ou encore négligeant avec certain de leur client.
En tout cas très bonne article, très bien structuré, avec de très bon exemple.
Merci.
Cordialement Sébastien de web-creativite.
[…] touche des milliers de site e-commerce basé sur le CMS OpenSource Prestashop. Tout est parti d’un article publié par l’agence […]
Comme quoi un trop grand nombre d’ecommercants ont une confiance totale en Prestashop ou bien d’autres CMS …
On ne parle pas des milliers de modules commercialisés et des gratuits fait à l’arrache …
Des audits de sécurité réalisés par des spécialistes, c’est toujours rassurant et cela vous garantie la sécurité un minium votre gagne pain.
De notre coté personne n’a rien jamais rien vu …
Merci pour la contribution.
Bonjour,
Merci pour votre commentaire.
Effectivement, c’est un peu le paradoxe de Prestashop. C’est une solution qui est accessible au grand public mais qui compte beaucoup trop de bugs pour pouvoir se passer d’un partenaire technique.
Pour notre part, nous utilisons Prestashop pour les besoins de nos clients car nous en connaissons les limites et les faiblesses.
Nous sommes en mesure de les contourner et de corriger les bugs afin d’assurer au e-commerçant, le bon fonctionnement de la plate-forme.
Prestashop est vraiment très riche fonctionnellement, c’est pour cela qu’il est massivement adopter. Mais Prestashop n’est pas suffisamment bien conçu et bien codé pour y porter une confiance aveugle.
Bonjour, je trouve votre article super et très inquiétant pour un novice comme moi.
Je voudrais savoir si je dois modifié ou pas mes paramètre prestashop? , j’ai actuellement la version 1.5.6.1
Merci pour votre aide.
Bonjour, si vous êtes en version 1.5 et que vous n’avez jamais changé ce paramètre, il n’y a pas de problème.
Bien que la configuration par défaut soit maintenant correcte, il y a des nombreux cas ou l’on a besoin d’activer cela et assez souvent, il n’est pas désactivé une fois le site web mis en ligne.
[…] blog de Wixiweb il est expliqué que le problème viendrai de la compilation […]
Merci pour ce travail, les exemples précis et surtout les solutions !
C’était juste pour dire que j’ai conservé cet article dans mes favoris et merci de cette info!
Bonjour,
Je voudrais savoir ce qu’il faut faire pour la version 1.6.0.9 de Prestashop pour ne pas avoir cette faille ouverte
Merci d’avance de vos réponses
Voila une article dont le sujet est a la fois intéressant et peu étudié. Je vais m’en servir pour enrichir mes formations par ailleurs
Je viens de me faire hacker mon presta 1.4.7.0
Le pirate a réussi à uploader un « gestionnaire de fichier » .php dans le dossier www/import
Mon /config/smarty.config.inc.php est bien priori bien configuré.
J’ai appliqué le correctif herfix.php au cas ou, mais je pense pas que ma boutique était concernée car en 1.4.7
http://www.aseox.fr/prestashop-pirate/
Bref, je ne sais plus trop ou chercher…
Auriez vous des idées ?
J’ai finalement trouvé la faille exploitée sur ma boutique, il s’agissait d’un vieux module d’avis clients, ou il était possible d’upolader des images pour accompagner l’avis.
Le hacker a uploadé un fichier .php a la place de l’image, il a ensuite tapé directement l’adresse maboutique.com/upload/son-fichier.php pour le lancer.
C’était le module Customer Testimonials v.1.4.2.
Bonjour,
l’article est ancien, mais cependant je voulais juste dire quel que soit le CMS que vous utilisez, il ne faut pas négligez la moindre faille. Souvent des failles de sécurité sont trouvées sur wordpress, cela peut avoir de gros dommages pour les sites web.
Une faille n’est pas à prendre à la légère.
[…] évitera certaines déconvenues rencontrées par pas mal de boutiques dans un passé pas si […]
Bien que cet article ne soit vraiment PAS amusant, je tiens à remercier Arnaud de pointer quelques imperfections de PrestaShop.
En fait, il m’a tenu en haleine toute la matinée.
Après maintes et maintes recherches et lectures, il est obligatoire, soit de :
1 – S’abonner à une « Google Alertes » sur ces mots clefs : « site:prestashop.com faille de sécurité » (faire la même chose pour son serveur, car la plupart des solutions de sécurisation PrestaShop requièrent une intervention sur le serveur, comme par exemple, SSH, SSL, suEXEC, Apache, etc…) et (tenter de) maintenir tout, tout seul…
ou
2 – Laisser un pro s’occuper de toutes les mises à jour de sécurité de son serveur et de son site PrestaShop
En fait, vu le nombre impressionnant de résultats d’une requête Google « site:prestashop.com faille de sécurité » réduite à une période d’un an donne le tournis :
https://www.google.fr/search?client=opera&q=« site%3Aprestashop.com+faille+de+sécurité »&sourceid=opera&ie=UTF-8&oe=UTF-8#q=site:prestashop.com+faille+de+s%C3%A9curit%C3%A9&tbas=0&tbs=qdr:y
Autant dire que c’est un travail à plein temps. Reste à calculer l’intérêt de signer un contrat avec un pro afin de se libérer un bon millier d’heures par an – sans parler des soucis en moins – ce qui pourrait, en fin de compte, s’avérer être la meilleure solution « efficacité + tranquillité ».
Diable d’article ! Il me hante depuis samedi :(
Si Arnaud pouvait commenter (ou mieux, faire un article sur) les services de web application firewall (WAF) proposés par CloudBric qui va jusqu’à prétendre être « La plus avancé des solutions de sécurité » avec un catalogue de clients prestigieux en bas de cette page :
Source : https://www.cloudbric.com/features/advanced/why-advanced/
En tenant bien compte de cette remarque fort pertinante tirée du blog de CloudBric :
« you need to stay on top of software updates and patches to keep your site secure »
(vous devez rester au top des mises à jour et des correctifs pour garder votre site sécurisé)
Source : https://www.cloudbric.com/blog/2015/09/6-steps-to-creating-a-secure-website/
En une question :
Quels pourraient être les avantages et inconvénients à utiliser un WAF dans l’hypothèse d’une faille de sécurité comme celle décrite sur cet article ?
Je reviens 2 mois et demi après la lecture de cet article. Pour faire court, cette lecture m’a fait devenir parano. Le terrain était peut-être favorable. Bref, à force de tourner autour du sujet de la sécurisation, j’en suis arrivé à la conclusion que le meilleur moyen de sécuriser un site, après le passage au HTTPS sur tout le site, c’était d’effectuer une certification PCI DSS, que j’ai obtenu après moult soucis, un travail de titan et une saignée dans les finances. Puis, je ne me suis pas arrêté en si bon chemin, j’ai rajouté une couche avec le Sceau « Norton Secure ».
Maintenant, mon site est blindé de chez blindé. Par contre, les ventes ont stagné, pour s’arrêter brutalement : Google a viré mon site du TOP 1000. Y’a dû y’avoir des fuites… Mes circuits sont niqués. Puis y’a un truc qui fait masse… J’ai dû rêver trop fort.
Moralité de l’histoire :
Il vaut mieux avoir un site vérolé qui vend, plutôt qu’un site sécurisé qui se fait virer des pages de résultats Google.
Bonjour Olivier et merci pour votre commentaire,
C’est vrai que l’on ne fait pas de la sécurité pour Google mais certains paramètres risques d’être pris en compte. Dans votre cas, c’est surement d’autres paramètres qui ont évolués et qui font que votre site a été déclassé.
Toutefois, je me permets une petite précision pour ceux qui lirait sans bien maitriser le sujet du HTTPS. La mise en place d’un certificat permettant de faire de HTTPS ne règle pas tous les soucis de sécurité. En effet, il permet deux choses :
– Éviter que les données qui transitent entre votre navigateur et le serveur puisse être interceptées, notamment dans un lieu public (Ex : votre login)
– Ne connaitre l’identité de la société a qui appartient le serveur.
Malheureusement, cela ne corrige pas les failles de sécurité applicatives.
Bonjour Arnaud,
Google a ses raisons, que la raison ne connaît point (Pascal). Ce qui m’étonne le plus depuis 10 jours que Google a black listé mon site, ce sont les victimes : Les pages avec du contenu UNIQUE rédigé à la main ont été black listées. Tandis que celles qui n’ont AUCUN contenu n’ont PAS été touchées.
Et il y en a ENCORE qui prêchent pour un contenu de qualité et qui black liste ce contenu de qualité…
En fait, j’ai besoin de rebondir sur ton commentaire du 27/12/2015, celui à propos du HTTPS. Olivier Andrieux, dans son excellent livre « Réussir son référencement web : Stratégie et techniques SEO » (édition 2015, revu et augmenté) écrit qu’un certificat SSL, celui là même qui procure les fameuses connexions sécurisées SSL, n’est PAS un gage de sécurité. Malheureusement, Olivier Andrieux ne donne AUCUNE explication technique de cette affirmation. Nous laissant sur notre faim.
Ses propos m’ont bien évidemment fait tomber de la chaise. Ensuite, j’ai pris mon bâton de pèlerin pour connaître les raisons de cette NON sécurisation de CERTAINES connexions HTTPS. Dans les faits, oui, Olivier Andrieux a raison, toutes les connexions ne sont PAS toutes égales. Pour s’en convaincre, il est nécessaire d’aller faire un test de son serveur sur le fameux site SSL Server Test :
https://www.ssllabs.com/ssltest/
De là, vous vous apercevrez des différents niveaux de sécurisation des serveurs, du meilleur « A+ » au pire « T ». C’est comme cela qu’interviennent les pirates qui réussissent à « casser » une connexion HTTPS : Faille POODLE, vulnérabilité « Heartbleed », faille « Forward Secrecy », usage de l’obsolète « SSL 3 », faille dans l’algorithme « RC4 », etc… etc…
Olivier Andrieux a donc raison en partie : Lorsque le serveur n’est pas parfaitement sécurisé, un certificat SSL sera facilement attaquable, et ne sécurisera rien.
Il est donc préférable d’obtenir un « A », ou mieux, un « A+ » qui sont le summum de la sécurisation d’un serveur; plutôt qu’un « B » qui comporte de grosses failles. Inutile donc de parler d’un niveau plus bas qui signifie : « Bienvenue à nos amis pirates ! ».
Conseil :
Vous aimez les films à la Hitchcock, qui vous font dresser les poils sur les bras, et vous glacent d’horreur ?
Testez le serveur de votre site préféré, eCommerce, Forum, Réseau social, service de paiement en ligne, site bancaire, impôts, etc…
Mais oui, vos coordonnées transitent sur ces serveurs pas tous très bien sécurisés : Vos nom, prénoms, login, adresse, email, téléphone, N° de compte bancaire ou administratif, documents administratifs, revenus, carte de crédit, etc…
Ce test va vous prendre 30 minutes, et vous allez adorer ;)
Et il y en a ENCORE qui prêchent pour un Web sécurisé et qui black liste les sites réellement sécurisés…
Merci pour l’information et pour cet article de qualité, très bien détaillé. Ce genre de failles peut être compromettant pour la sécurité d’un site web Prestashop…
[…] blog de Wixiweb il est expliqué que le problème viendrai de la compilation […]
[…] faille de sécurité dans Prestashop Franchement j’avais pas vraiment fait attention, mais Wixiweb a levé le voile sur ce problème, une faille est bien présente… elle est liée au Debug de Smarty. C’est-à-dire […]
[…] évitera certaines déconvenues rencontrées par pas mal de boutiques dans un passé pas si lointain […]