Je viens à l'instant de placer sur
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 
J'ai aussi vu le film après et je le trouve confus, on y voit les scènes mais les engrenages manquent cruellement. Je recommande de loin le bouquin.
Fidèle à la loi des séries et des jeux de mots à la con, je ne pouvais m'empècher de vous faire part du 
