Une nouvelle version du scanneur de vulnérabilités web Wapiti est disponible.
Wapiti est un logiciel libre sous licence GNU GPL v2 permettant d'auditer la sécurité des applications web. Il est développé en Python et s'utilise en ligne de commande. Cette version est principalement une refonte du logiciel et la grande majorité des changements s'est faite « sous le capot » pour prendre en charge des fonctionnalités manquantes comme les nouveaux éléments du HTML 5 et les liens générés par du JavaScript.
Présentation
Wapiti est un logiciel libre sous licence GNU GPL v2 permettant d'auditer la sécurité des applications web. Il est développé en Python et s'utilise en ligne de commande. Il fonctionne en trois étapes :
- premièrement, la découverte de l'application web via l'exploration des pages du site. L'objectif étant de trouver le plus de liens et formulaires acceptant la soumission de données.
- deuxièmement, la phase d'attaque en boîte noire qui consiste à envoyer des données formatées spécialement dans le but d'essayer de causer des problèmes dans l'application web (messages d'erreurs, timeout, etc). Le comportement de l'application web face à ces données permet de déterminer si un script est potentiellement vulnérable. Par exemple la présence d'une apostrophe dans un champ de formulaire peut provoquer à sa soumission une erreur SQL si l'auteur de l'application web n'a pas échappé correctement une variable avant de l'intégrer dans une requête SQL.
- dernière étape, la génération d'un rapport de scan dans un format choisi par l'utilisateur (JSON, texte, HTML, XML…).
Améliorations sous le capot
Cette version est principalement une refonte du logiciel et la grande majorité des changements s'est faite "sous le capot". Le code a été revu et corrigé dans un objectif de gain en stabilité et en lisibilité. L'utilisation d'un vérificateur PEP8 a permis d'augmenter la qualité du code. Un gros travail a été fait sur la gestion de l'unicode qui causait de nombreux bugs dans la précédente version (le web c'est comme une boîte de chocolat, on ne sait jamais sur quel(s) jeu(x) de caractères on va tomber). La bibliothèque httplib2 a été remplacée par requests. En dehors d'être plus agréable à utiliser, cette bibliothèque apporte surtout la gestion des cookies qui étaient auparavant gérés directement dans Wapiti.
Le module lswww, la partie de Wapiti chargée d'explorer les pages web et de recenser URLs et formulaires, a aussi été fortement amélioré. L'objectif était de combler les lacunes mises en évidence dans un article du magazine MISC (n°65, janvier/février 2013). Pour cela, l'analyseur HTML a été revu pour prendre en charge certaines balises oubliées ainsi que les nouvelles balises de formulaires apparues avec HTML5. Afin de trouver plus d'URL, un petit analyseur de fichiers SWF a aussi été rajouté ainsi qu'un mini interpréteur javascript (qui n'en est qu'à ses balbutiements) basé sur PyNarcissus. Ces modifications ont permis à Wapiti d'obtenir un score de 48% sur Wivet, ce qui le met à peu près au même niveau que deux de ses concurrents NetSparker et w3af.
Nouvelles fonctionnalités
Une limitation des anciennes versions ne permettait pas au logiciel d'injecter ses payloads dans les paramètres de l'URL sur les requêtes HTTP POST. C'est-à-dire que sur un formulaire envoyé par POST, seuls les champs "input" étaient attaqués et pas ceux présents dans l'URL (spécifiée via l'attribut "action" du formulaire). C'est maintenant corrigé. De plus, Wapiti est dorénavant capable de s'attaquer aux formulaires d'envoi de fichier : il gère le multipart. Les injections se font sur le nom de fichier envoyé qui est potentiellement mis en base de données par l'application web ou peut être passé à des commandes shell sans vérification préalable.
Des informations plus détaillées sont données quand une vulnérabilité a été trouvée. Ainsi, on retrouvera dans un rapport de scan la requête HTTP qui a causé le problème ainsi qu'une ligne de commande cURL permettant de reproduire le problème (très pratique pour avoir un proof-of-concept rapide).
Pour une liste exhaustive des nouveautés, je vous invite à lire cet article de mon blog.
Remerciements
Je tiens à remercier toutes les personnes m'ayant aidé sur cette nouvelle version. En particulier les membres de deux communautés liées à l'Open-Source qui méritent d'être connues, Alionet.org (pour leur aide sur les tests et le packaging pour openSUSE) et Gimp-Attitude (pour le nouveau logo).
Aller plus loin
- Wapiti (881 clics)
- Les nouveautés de la version 2.3.0 en détail (114 clics)
- De l'importance et de la difficulté du packaging Python : mon combat avec le setup.py et py2exe (84 clics)
- Alionet.org : communauté francophone openSUSE (27 clics)
- Gimp-Attitude : communauté d'utilisateurs de GIMP (38 clics)
# Détection d'erreur
Posté par barmic . Évalué à 2.
Je ne connaissais pas du tout, c'est intéressant. Comment il fait pour déterminer si une attaque a réussi ou non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Détection d'erreur
Posté par devoop . Évalué à 1.
Il y a deux approches principales dans Wapiti :
- la recherche d'une chaîne de caractères particulière dans la réponse renvoyée par le serveur (particulièrement vrai pour la détection des XSS ou l'injection d'entête HTTP)
- la détection d'un délais d'attente (timeout) provoqué intentionnellement lors de l'attaque (ex: injection d'une instruction sleep() dans une requête SQL ou d'une commande sleep dans un shell. Il est aussi possible de provoquer des calculs intensifs pour provoquer ce délais, par exemple via la fonction BENCHMARK pour MySQL)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.