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: , , , ,

jan 17

Comme vous le savez, NBS System fait aussi de la sécurité informatique et notamment pas mal de test d’intrusion, externe, interne, web, applicatifs etc…

Dans ce contexte, nous créons régulièrement des petits articles de synthèse pour nos connaissances, pour des journalistes ou des clients. Certains de ces articles sont maintenant un peu vieillots (6 mois à deux ans) mais les principes de fond ne changent pas si vite que cela.

Je me permets donc de vous faire cadeau de trois de nos articles sur la sécurité des technologies Web et plus particulièrement Web 2.0, en espérant que cela servira à vos équipes pour faire baisser le taux de sites vulnérables. (D’après un rapport de notre labo de sécurité, sur 15 applicatifs web testés l’an dernier, 12 étaient très vulnérables, 2 légèrement (par Xss) et 1 seulement sans faille connue)

Une chance cependant pour les aficionados de Zend et Magento, le Framework Zend est bien sécurisé sur le point des XSS et SQL Injections. Les hébergeurs ont un rôle important également à jouer en patchant et sécurisant en continu, les développeurs également, en ne déportant pas de décisionnel ou de code sensible en Ajax/Javascript sur le poste client etc…

D’une manière générale :

  • Pas de code sensible et/ou décisionnel déporté sur le browser du client
  • Pas de version vulnérables des services LAMP (Apache et PHP tout particulièrement)
  • Pas de certificat auto signés
  • Un filtrage DRASTIQUE des entrées utilisateurs (formulaires, champs recherches etc…)
  • Si possible n’accepter que [a-z][A-Z][0-9] et le tiret pour les adresse
  • Un bon Firewall et un bon Reverse Proxy
  • Un DNS en dernière version non vulnérable à la faille de Kaminsky
  • Protéger toute zone d’administration par un .htaccess

Trois maximes guident notre métier :

  • La sécurité est un processus, pas un produit
  • La sécurité est une chaine, le maillon faible est toujours visé
  • La sécurité à un coût mais elle n’a pas de prix

(Ca semble plus commercial au premier abord mais ceux qui se sont déjà fait hacker savent de quoi je parle ;) )

article-dns-pinning
web-20
sécurité & web 2.0

écrit par Philippe Humeau \\ tags: , ,