Alors que
Wapiti a dépassé doucement mais surement la barre des 16200 téléchargements sur
SourceForge, les plus observateurs auront remarqué la sortie d'une version 2.0.0 béta avant-hier soir.
La question que vous vous posez certainement c'est comment l'on peut passer d'une version 1.1.7-alpha à une version 2.0.0-béta...
Tout simplement avec beaucoup de changements !! Et il s'en est passé des choses depuis la sortie de la précédente version.
Premièrement, le nombre de développeurs est passé de 1 à 3 grace à l'aide de 2 développeurs espagnols de
ICT-Romulus.
Leur souhait était de pouvoir apporter des nouvelles fonctionnalités à
Wapiti, notamment pour faciliter son intégration dans un projet de framework J2EE basé sur
Maven (si j'ai tout compris lol).
Dans tous les cas ils ont proposé de participer au développement de
Wapiti afin que tout les utilisateurs puissent profiter de leurs idées et de leurs modifications

Cela est passé par la mise en place d'
un espace SVN pour le projet pour faciliter le développement.
Leur objectif principal était de travailler sur le rendu final fournit par
Wapiti. Ainsi il est possible d'obtenir un compte rendu des vulnérabilités dans 3 formats différents : XML, HTML et texte simple. Pour cela les options -f (format) et -o (output) ont été rajoutés.
Ils ont aussi réussi à séparer les payloads du code, ce qui rend plus simple leur ajout. Le code a été aussi revu et est plus modulaire.
Des règles de détection pour les failles SQL ont aussi été rajoutées.
De mon côté j'ai pû enfin résoudre le problème des boucles sans fin lors du scan d'urls en ajoutant l'option -n (ou --nice) qui permet de définir un
"seuil de tolérance" au niveau des urls du même type.
Ainsi si les pages suivantes ont déjà été scannées :
http://server/p?a=x&b=1&c=xhttp://server/p?a=x&b=2&c=xhttp://server/p?a=x&b=2&c=yAvec un seuil de 2, quand l'url
"http://server/p?a=x&b=3&c=x" sera trouvée, elle sera exclue car déjà 2 urls du même pattern ont déjà été trouvées (
http://server/p?a=x&b=*&c=x).
Même chose avec l'url
http://server/p?a=x&b=2&c=z.
Par défaut aucun seuil n'est spécifié (ce qui revient à le fixer à 0). A vous de voir la valeur qui vous semble juste (10 me parait en bon compromis pour faire beaucoup de possibilités sans tourner en boucle).
J'ai aussi réussi à faire fonctionner l'authentification HTTP (option -a) en pompant sur le code de
sqlmap. Même si les instructions sont sensiblement différentes par rapport à ce que
Wapiti faisait, le principe est le même et je ne saurais pas dire pourquoi ça ne fonctionnait pas auparavant (alors que proxies et cookies fonctionnaient)... un des mystères de
Python
Malheureusement, étant donné la façon dont les modules
urllib2 fonctionnent, il est préférable de retirer l'authentification sur le serveur et d'utiliser
Wapiti simplement. En effet pour chaque url, si l'authentification est présente,
Python va émettre deux requêtes : une première sans authentification qui va renvoyer une erreur 401. Et une seconde avec les identifiants pour passer la vérification
Enfin la nouvelle méthode de scan XSS est complètement implémentée et la librairie
Beautiful Soup a été mis à jour.
Pour la prochaine version, différents changements sont à faire comme pouvoir gérer les erreurs HTTP 500 (nouveau bug), améliorer la qualité des rapports de scan, limiter le nombre de plantages liés au décodage Unicode

et enfin travailler sur la vitesse de scan de
Wapiti.
En effet lors de certains tests, on s'apperçoit que
Wapiti peut avoir un effet
DoS sur le serveur web (voir que les 152 process lancés par Apache pour répondre aux requêtes sont tous occupés c'est pas top...) Il faut donc essayer d'envoyer le plus de requêtes possibles par connexion (ou trouver la juste proportion entre les deux)
Dans tous les cas, je ne peux que vous conseiller de passer à cette nouvelle version qui apporte des fonctionnalités importantes

Télécharger
Wapiti-2.0.0-béta.