mar 12

Bonjour à toutes & à tous,

Je suis content de revenir parmis vous pour discuter d’un sujet qui a refait l’actualité en mon absence semble t’il : Magento & la sécurité.

Après une belle vague de 3 Cross Site Scripting (XSS) à laquelle nous avons essayé d’apporter des solutions avec Gabriel, une nouvelle faille de type CSRF a été révélée, un peu sauvagement et un peu tôt visiblement.

En général, dans le monde des experts sécurité, on évite de publier une vulnérabilité avant d’avoir prévenu l’éditeur du produit et avant de lui avoir donné le temps réagir. Un mois est une valeur qui n’a rien de conventionné mais qui est communément accepté comme le « minimum ». Le soucis c’est que quand une faille affecte ™Windows©, ©Mic®osoft™ peut déployer un patch correctif par son système automatisé de mise à jour.

Pour un site Web commerçant c’est un peu plus complexe. On ne fait pas une montée de version comme ca, du jour au lendemain. Déjà même pour ce blog WordPress et même en étant moi même un IT, j’ai 8 extensions à mettre à jours et je ne le fais pas par crainte de planter le blog. Alors que dire pour un site de E-commerce.

Donc, quand on a une faille sur Magento, on peut parier que le correctif se fera « à la main » et pas par une montée de version, dans le meilleur des cas. La plupart du temps, le correctif est tout simplement ignoré, on vit avec la faille en espérant que personne ne la remarque.

Revenons à nos moutons : le Cross Site Request Forgery aka « CSRF »…

Encore un OVNI pour beaucoup de Web developpers mais une réalité terrain pour les personnes mal intentionnées. La sécurité « Web 2.0 » (chapeau les marketeux) est une chose un peu complexe, il existe de multiples attaques (XSS,SQl injection,anti dns pinning, CSRF, Sop, smuggling, etc…) et un article complet aurait bien sa place à l’avenir sur le sujet.

Dans l’immédiat, il est important de comprendre que la faille vient souvent d’un mauvais usage (ou d’un oubli d’usage) de Zend. Zend est propre et filtre correctement tout un tas de chose qui peuvent compromettre un site, mais quand on ajoute « à la main » du code, sans appeler les routines natives Zend, on perd cette protection. Attention, ce qui vaut ici pour Varien vaut aussi pour les développeurs Web qui enrichisse un site de E-commerce de leurs propres créations. Zend protège mais ne fait pas tout non plus contre toutes les attaques…

Pour se protéger, il existe des méthodes simples, à mettre en place systématiquement (à mon sens). Dans un premier temps, les URLs d’admin doivent être obfusquées, cachées, en tout cas difficiles à trouver. Pour se faire, garder le chemin par défaut n’est pas une idée à retenir :)

Dans le fichier qui paramètre cette URL (app/etc/local.xml), on peut modifier la ligne :
<frontName><![CDATA["mettre la fin d'url souhaitée ici"]]></frontName>

Ensuite, comme après chaque manipulation fondamentale, on efface son cache (dans var/cache/)
Si vous ne trouvez pas le frontName, vous pouvez l’ajouter dans des tags <config></config>

C’est une protection de fond et autant, au passage, ajouter celle qui était déjà mentionnée dans l’article sur les correctifs XSS : le htpassword. Comme cela, votre admin est difficile à trouver et ensuite pour y entrer, il faut avoir un premier login/pass… dur.

<LocationMatch “/mettre la fin d’url souhaitée ici” >
AuthUserFile /var/www/htdocs/.htpasswd
AuthType Basic
AuthName “Magento Backoffice Login”
Require valid-user
</LocationMatch>

Je pense qu’on peut aussi ajouter : (j’ai pas testé cependant)
Allow from 111.222.121.212 (remplacer par son IP)
Satisfy Any


Comme ca, on peut soit venir de l’ip ou avoir le mot de passe. Soit l’un, soit l’autre, on peut faire que l’un ou que l’autre. Si on vient de la bonne IP, évidemment, on a pas à taper le mot de passe. Avec ca, finit les XSS ou CSRF sur vos backoffice d’admin.

Ceci étant, ça fait deux série de vulns en 2 semaines, ça veut dire qu’il va falloir passer tout cela au crible, je suppose aussi que des experts sont déjà sur le coup et en ont déjà communiqué à Varien mais attendent un mois avant de les publier.

Allez, demain ou lundi on parlera de ces inclusions de contenus qui ralentissent les beaux sites web que vous mettez en place :)

écrit par Philippe Humeau \\ tags: , , , ,