Monday, 15. September 2008, 20:49:00
Je viens à l'instant de placer
sur SourceForge une nouvelle version de
Wapiti.
C'est une version alpha (avec tout que ça implique) de la prochaine version à venir (la 1.1.7). L'objectif étant de montrer vers où se dirige
Wapiti dans son développement, quelles sont les améliorations en cours et permettre à ceux qui ont des modifications à soumettre de se baser sur un code plus à jour que la version précédente.
Je compte aussi sur tous ceux qui utiliseront cette version pour soumettre les bugs qu'ils trouveront, en particulier s'il s'agit de stabilité.
La principale nouveauté c'est la nouvelle fonction de détection de failles XSS (actuellement nommée
"new_attackXSS") qui se base sur
mes expérimentations avec la librairie Beautiful Soup pour détecter où se situe le code injecté dans la page (d'un point de vue DOM/HTML...) et choisir en conséquence le payload le mieux adapté.
Ce n'est pas la seule amélioration sur ce point puisque vous verez dans le fichier
XSS.py un certain nombre de
payloads dont l'objectif est de pouvoir passer d'éventuels filtres anti-XSS.
Parmis les filtres visés il y a :
- ceux qui filtrent sur le mot "script"
- ceux qui retirent les quote (apostrophes) et double-quotes (guillements)
- ceux qui filtrent les signes inférieur et supérieur des balises HTML/XML
L'algorithme pour détecter les XSS a sensiblement changé :
Pour une url que l'on aura trouvé, avec des paramêtres A, B et C, on va essayer d'injecter du code dans chacune des variables séparément mais toutes ces variables resteront présentes dans l'url telle qu'on l'a trouvée (le payload se
"déplace" de variables en variables dans l'url)
Au lieu d'attaquer directement avec un payload,
Wapiti commence par injecter un identifiant alpha-numérique de 10 caractères et vérifie que se dernier est bien injecté dans la page.
Si c'est le cas, il va étudier cette page et pour chaque occurence de l'identifiant il va déterminer quelle liste de payloads utiliser en fonction de sa position dans la page.
Dès qu'un payload semble fonctionner, il sort de la boucle et passe à la variable suivante (ou la page suivante s'il a fait toutes les variables)
La plupart des payloads sont
"user-friendly", il suffit de recopier l'url proposée par
Wapiti pour voir un beau
"alert". Mais d'autres ne donnent pas un résultat immédiatement visible (par exemple ceux qui injectent un String.fromCharCode) pour des raisons de taille du payload.
Enfin parmis les payloads on trouve ceux qui cherchent juste à appeler un script externe.
Dans l'ensemble, l'objectif était que
Wapiti puisse donner à l'utilisateur une url d'attaque se rapprochant au mieux de ce qu'il aurait pû trouver lui-même avec son navigateur.
Les navigateurs qui (mattez la transition
) ne réagissent malheureusement pas tous de la même façon devant une page malformée. Lors de l'injection du payload, celui-ci peut se retrouver à différents endroits de la page, par exemple dans le
"title" de la page alors qu'on le retrouvera puis loin dans le
"href" d'un lien ou enfin dans un code CSS.
Pour commencer, on ne peut pas injecter directement du javascript dans la balise
title : il faut fermer cette balise puis ouvrir une balise script.
Comme le payload est propre à la variable on va le retrouver aux différents endroits correspondants de la page. Donc notre balise
title que l'on aura fermée va se retrouver dans le
href et dans le code CSS...
Puisque les navigateurs ont généralement une lecture linéaire, le résultat obtenu avec la première injection devrait être satisfaisant... Mais si on est obligé de passer par la seconde occurence du payload dans la page, il va falloir faire avec le code injecté dans la balise title qui peut rendre le code HTML chaotique et empécher l'interprétation du payload en seconde position...
Cette interprétation étant propre au navigateur (sa capacité à gérer les erreurs), on ne peut jamais être à 100% sûr que le payload généré sera fonctionnel sur l'un des principaux navigateurs.
Dans
Wapiti, la gestion de ces erreurs se fait à l'aide de
Beautiful Soup qui se rapproche probablement du comportement qu'aura un navigateur.
J'ai aussi fait des tests avec
Tidy et les différences sont radicales. Alors que
Beautiful Soup cherche plutôt à fontionner malgré les erreurs,
Tidy les corrige ou les supprime donnant des résultats parfois surprenants.
C'est l'une des raisons que me pousse à me recentrer sur l'utilisation de
Beautiful Soup pour les futures versions de
Wapiti, la seconde raison d'importance est qu'il est difficile pour un utilisateur de Windows de disposer de
Tidy avec
Python (les pauvres, déjà qu'ils ont pas un OS facile
)
Pour terminer sur cette partie, ce nouveau
"moteur" XSS ne concerne pour le moment que la méthode GET, je dois encore la mettre en place pour le POST.
Il y a aussi un système d'historisation des requêtes (pour la détection des XSS permanents) qui est en cours de réécriture.
En dehors de ça, quelques bugs corrigés, le plus important concernait les formulaires où la méthode (GET ou POST) n'était pas spécifié. Désormais GET est utilisé par défaut (comme voulu par les standards HTML).
Wapiti 1.1.7-alpha
, par conséquent il n'est pas impossible que vous rencontriez des erreurs lors de l'installation 
Cela dis 
(même si j'avais donné quelques infos en commentaire sur la dernière béta 
).
), ici le maximum de requêtes possible sera envoyé à travers une même connexion. Non seulement le serveur ne se fatigue pas mais en plus on obtient un gain important en vitesse de scan 
WIDGETIZE