JSSI 2012 - Retour d'expérience sur les outils d'audit d'applications Web en boite noire

Laurent Butti (Orange Portals)
edit:slides
« Retour d’expérience sur les outils d’audit d’applications Web en boite noire » (une publication académique sur le sujet est disponible ici : http://www.cs.ucsb.edu/~adoupe/static/black-box-scanners-dimva2010.pdf )

Travaille à Orange Portail, qui fait des applications pour Orange.fr et qui héberge aussi les sites. Laurent à pour mission d’améliorer la sécurité dans le cycle de développement de ces applications.

Il s’agit d’un panorama sur les outils d’audit et ce qu’ils apportent mais aussi ce qu’ils n’apportent pas.

Les applications web sont hautement sensibles, elles sont peu ou pas protégés des requêtes provenant de l’extérieur. De plus l’intégralité de la sécurité repose uniquement sur les développeurs là ou traditionnellement cette sécurité était répartie entre tous les acteurs.

Les principes de sécurité sans processus existant sur lesquels se greffer, c’est très difficile de partir de 0 en terme de sécurité si on a pas déjà un cycle de développement clairement défini, avec des phases de test déjà identifiées.

Sans audit récurrent, la sécurité de l’application va se dégrader après l’implémentation des correctifs du premier audit. L’approche consiste donc à utiliser un scanner boite noire comme n’importe quel autre outil de test, et à l’intégrer dans le cycle de vie. Lors des résultats de scan, on va orienter les développeurs vers les bonnes pratiques (comme on peut le faire dans n’importe quel audit applicatif).

L’intérêt de l’outillage, c’est d’assister l’auditeur, ou bien lorsqu’on à pas les compétences ou les ressources. Cependant, il faut savoir ou sont les limites de ces outils pour les utiliser à bonne escient, et ne pas faire reposer toute la sécurité sur les résultats de ces outils.

Un web scanner se repose sur 4 briques :

Crawler : récupération de tous les points d’entrée de l’application
Injecteur : insertion de chaines de test pour générer (ou non) des erreurs.
Algorithme de découverte de failles : analyse des retours des injecteurs.
Reporting : génération d’un rapport avec des préconisations standardisées.

La plupart de ces scanners n’offrent pas une grande qualité d’analyse lorsqu’ils sont utilisés en mode full automatique. Ils n’arrivent pas à simuler le parcours client, à franchir les formulaires d’authentification etc… le crawler n’est pas toujours capable de détecter qu’il est dans un puit de crawling.

Coté briques d’injection, les résultats sont variables, certaines ne sont par exemple pas capables d’effectuer des injections sur les headers ou les cookies. Coté détection d’XSS, il n’est pas forcément évident de détecter ce type de failles tellement elles sont complexes, la plupart des scanners se contentent donc d’injecter des vecteurs connus comme fonctionnels et d’analyser s’ils sont retournés quelquepart.

Coté injection SQL, les détections se font efficacement à l’aide d’injections SQL en aveugle. Toute la problématique réside dans la construction de vecteurs de détection facilitant la découverte des failles. L’exploitation importe peu, c’est la détection qui prime dans l’utilisation de ce genre d’outils.

Pour ce qui est des contraintes opérationnelles de mise en oeuvre de ces scanners, il est difficile de mettre en place l’audit des sites en production avec de tels outils. C’est plutôt déconseillé ou au mieux en one-shot. Il vaut mieux les déployer sur des plateformes de qualification au sein d’un processus d’intégration continue.

Ces outils sont bloqués par certaines technologies (flash, json, amf, etc…). Et la partie crawling à besoin d’un coup de main pour accrocher des points d’entrée utiles.

Pour conclure, W3AF et Arachni sont pas trop mal, mais si le site est complexe, il vaut mieux utiliser un proxy d’analyse comme Burp.