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.

prestashop-qualite

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

exemple-securite-prestashop
exemple-equipe
exemple-xgames
exemple-arthus

prestashop-marketplace

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.

fonctionnement-interne-prestashop-smarty

  1. Les données issues de la base de données sont chargées dans des objets métiers (Tag, Product, Cart, etc).
  2. Le contrôleur de la page demandée passe les objets au moteur de template
  3. 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

smarty-prestashop-conf

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.

prestashop-faille-securite

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.

prestashop-price

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.

prestashop-facebook

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.

prestashop-faille-securite-ip

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.

prestashop-faille-securite-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.

prestashop-configuration

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.

prestashop-securite-solution

[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.