Que la fortune se jette sur vous par surprise, que les anges du E-commerce bénissent le berceau de votre nouveau site web, que les trompettes de la gloire chante leur mélodieuse mélopée dans le creux de vos oreilles. Bref tout le meilleur à vous, à tous, que 2010 soit une année joyeuse !

Pour se chauffer en ce début d’année, une petite faille dans Magento ca vous dit ?

Le vieux démon est de retour chez Varien, le XSS

Je ne redécrirai pas cette classe de vulnérabilité car ce post précédent était assez détaillé sur le sujet et la littérature ne manque pas.

Magento, vu l’impressionnante quantité de code qu’il contient, est relativement bien géré sur ce plan, mais… L’usage de Zend et les bonnes pratiques mises en place par Yoav et Michael ne sont pas toujours suffisantes. Un moment d’égarement, un vieux bout de code jamais audité, personne n’est à l’abri.

La vulnérabilité du jour

En fait, elle est relativement mineure en terme de possibilités car il faut déjà être un utilisateur authentifié pour pouvoir l’exploiter. Ceci étant, une fois loggé dans le backoffice, peut mener des actions assez dangereuses en terme de Cross Site Scripting.

Les versions touchées de manière certaines sont les 1.3.2.xx en community edition, peut être que d’autres sont aussi vulnérables.

Le paramètre « product_name » n’est pas correctement nettoyé, « sanitized » en anglais. Cette procédure consiste à vérifier que la variable passée ne contient pas de « *’%$ et autres caractère spéciaux permettant de passer du Javascript.

Idem pour les variables : Product SKU, Product description, customer group name, category name, attribute set, sitemap path, customer tax class, product tax class, taxe rate id qui ne sont pas non plus nettoyées correctement.

Post original de la faille

Savoir si l’on est vulnérable à cette XSS

1. Allez dans le backoffice
2. Cliquez dans catalogue
3. Mettre les réglages par défaut et cliquer sur continuer
4. Entrez « <script>Alert(‘Cross Site Scripting’);</script>
5. Entrez des données au hasard dans les autres champs et cliquez sur ‘Save’
6. Cliquez sur Ventes->Commandes et « créer une nouvelle commande »
7. Choisissez un client
8. Cliquez sur « Ajouter un produit »
9. Sélectionnez le produit nouvellement créé et ajouter le produit à la commande
10. Et hop, une faille XSS !

Une méthode complète de tests ?

Bien évidemment, pour éviter cela, une analyse statique et/ou dynamique du code source produit après un commit SVN serait pertinent chez Varien. Évidemment, si c’est le cas chez Varien, c’est aussi vrai pour les web agency qui surcharge les classes du framework ou ne code pas toujours dans les normes.

Comment se protéger correctement ?

Déjà, pas de panique, la faille n’est pas gravissime car elle nécessite d’être déjà authentifié pour nuir. Techniquement, si quelqu’un a les accès en backoffice et veut nuir, ca risque d’être plus simple de faire autrement que de faire une XSS. Cela peut être une méthode subtil pour nuir cependant.

Imaginons qu’un concurrent réussisse à se connecter à votre backoffice, il lui sera alors possible de capter tous vos clients ou de leur nuire en infectant leurs browsers voir en détournant les commandes… Gênant.

Si (et ce n’est pas prouvé pour le moment), si la vulnérabilité touche aussi la version EE, les rôles peuvent être très séparés et du coup un stagiaire avec des droits de pioupiou pourrait injecter une XSS auprès des clients.

Que faire :

1. Mettre un mot de passe fort et ne faire des comptes qu’aux personnes de confiance
2. Déporter son backoffice sur un autre sous domaine et lui mettre un HTaccess
3. Mettre à jour sa version en 1.4 CE ou 1.7 EE
4. <chez Varien> auditer le code source <chez les webagency> faire auditer le site une fois qu’il est finit