Il y a un code pour gérer le JS (savamment baptisé LameJS et qui porte bien son nom) capable d'extraire des infos des codes javascripts (arguments des fonctions, valeurs de variables, ça gère aussi la concaténation de chaines), le tout se base sur pynarcissus (un parseur qui permet d'obtenir un AST).
Il n'y a pas encore d'utilisation d'un navigateur headless mais ça peut être une solution alternative à un module agissant comme proxy interceptant (mentionné dans les commentaires sur ZAP).
Evidemment c'est + de ressources et + de dépendances pour le logiciel mais ça pourrait être optionnel.
Il faudrait s'assurer que les résultats obtenus ne soient pas des faux positifs en ouvrant les URLs remontées via un navigateur.
A noter que pour vérifier la véracité de l'injection il faudra souvent désactiver la protection anti-XSS intégrée au navigateur (XSS auditor pour Chrome par exemple).
S'il s'agit de faux positifs je serais ravi de me pencher sur leur correction. Il est possible de créer des issues ici : https://sourceforge.net/p/wapiti/bugs/
Il y a beaucoup de paramètres qui rentrent en jeu comme la réactivité du serveur et si il y a beaucoup de formulaires ou des URLs avec beaucoup de paramètres.
Un scan peut facilement durer plusieurs jours si il y a beaucoup d'URLs c'est pour cela qui sont l'on veut chercher une faille dans une application web connue il est préférable de la déployer chez soit pour la tester avec un jeu d'essai minimum (ex pour une application de forum: une section, un topic, un message, un membre, un message privé, etc ça peut suffire)
Après il faut jouer avec les options proposées par Wapiti comme -d et -S. Souvent une profondeur de 3 ramène déjà suffisamment de liens sur un site moderne.
Pour le reste et par rapport aux autres commentaires, Wapiti est un logiciel libre et c'est aussi la liberté d'utiliser le logiciel comme on l'entend. Chacun est sensé connaître la loi, la responsabilité est bien sûr laissée à celui qui utilise le logiciel.
La force de Burp ou ZAP (que j'utilise moi-même) c'est surtout le fonctionnement en proxy intercepteur qui permettent de trouver efficacement les requêtes dynamiques (ajax / flash et compagnie) et c'est là ou Wapiti aura tendance à pécher.
Après Wapiti a un fonctionnement totalement automatique là où une utilisation de ZAP requerra plus d’interaction humaine.
Wapiti sera bien pour faire le gros du boulot et trouver les failles les plus évidentes rapidement et ZAP sera à privilégier pour trouver les failles moins évidentes sur lesquelles il faut fouiller un peu et qui demanderont plus de minutie.
Ce côté automatique de Wapiti peut être utile pour mettre par exemple en place un process de test sécurité continu sur une application web.
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)
Oui c'est à peut près ça, tester le max d'options, modules en tout genre jusqu'à trouver une erreur, crash, fonctionnement anormal.
La précédente version avait des difficultés avec le décodage de l'unicode sur les sites exotiques (caractères chinois et compagnie), ce qui est normalement réglé pour la future version mais ça vaut toujours le coup de tester :)
Et évidemment sur pages avec du mauvais HTML, balises pas fermées etc… mais ça on en trouve partout :p
[^] # Re: Merci
Posté par devoop . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 1.
Très certainement des faux positifs. Ce sera l'occasion de faire la chasse aux bugs :)
[^] # Re: Scanner "statique" : intérêt limité ?
Posté par devoop . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 3.
Il y a un code pour gérer le JS (savamment baptisé LameJS et qui porte bien son nom) capable d'extraire des infos des codes javascripts (arguments des fonctions, valeurs de variables, ça gère aussi la concaténation de chaines), le tout se base sur pynarcissus (un parseur qui permet d'obtenir un AST).
Il n'y a pas encore d'utilisation d'un navigateur headless mais ça peut être une solution alternative à un module agissant comme proxy interceptant (mentionné dans les commentaires sur ZAP).
Evidemment c'est + de ressources et + de dépendances pour le logiciel mais ça pourrait être optionnel.
[^] # Re: paquet pypi
Posté par devoop . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 3.
J'y ait déjà pensé mais je ne me suis pas encore penché dessus :)
[^] # Re: Merci
Posté par devoop . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 4.
Il faudrait s'assurer que les résultats obtenus ne soient pas des faux positifs en ouvrant les URLs remontées via un navigateur.
A noter que pour vérifier la véracité de l'injection il faudra souvent désactiver la protection anti-XSS intégrée au navigateur (XSS auditor pour Chrome par exemple).
S'il s'agit de faux positifs je serais ravi de me pencher sur leur correction. Il est possible de créer des issues ici :
https://sourceforge.net/p/wapiti/bugs/
[^] # Re: Parallélisme
Posté par devoop . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 6.
Il y a beaucoup de paramètres qui rentrent en jeu comme la réactivité du serveur et si il y a beaucoup de formulaires ou des URLs avec beaucoup de paramètres.
Un scan peut facilement durer plusieurs jours si il y a beaucoup d'URLs c'est pour cela qui sont l'on veut chercher une faille dans une application web connue il est préférable de la déployer chez soit pour la tester avec un jeu d'essai minimum (ex pour une application de forum: une section, un topic, un message, un membre, un message privé, etc ça peut suffire)
Après il faut jouer avec les options proposées par Wapiti comme -d et -S. Souvent une profondeur de 3 ramène déjà suffisamment de liens sur un site moderne.
Pour le reste et par rapport aux autres commentaires, Wapiti est un logiciel libre et c'est aussi la liberté d'utiliser le logiciel comme on l'entend. Chacun est sensé connaître la loi, la responsabilité est bien sûr laissée à celui qui utilise le logiciel.
[^] # Re: VS ZAP et le reste ?
Posté par devoop . En réponse à la dépêche Wapiti 3.0.0 : Nouvelle version du scanneur de vulnérabilités Web. Évalué à 10.
Bonjour,
La force de Burp ou ZAP (que j'utilise moi-même) c'est surtout le fonctionnement en proxy intercepteur qui permettent de trouver efficacement les requêtes dynamiques (ajax / flash et compagnie) et c'est là ou Wapiti aura tendance à pécher.
Après Wapiti a un fonctionnement totalement automatique là où une utilisation de ZAP requerra plus d’interaction humaine.
Wapiti sera bien pour faire le gros du boulot et trouver les failles les plus évidentes rapidement et ZAP sera à privilégier pour trouver les failles moins évidentes sur lesquelles il faut fouiller un peu et qui demanderont plus de minutie.
Ce côté automatique de Wapiti peut être utile pour mettre par exemple en place un process de test sécurité continu sur une application web.
[^] # Re: Détection d'erreur
Posté par devoop . En réponse à la dépêche Sortie de Wapiti 2.3.0. É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)
[^] # Re: Merci
Posté par devoop . En réponse au message Le projet Wapiti cherche des testeurs et des traducteurs. Évalué à 2.
Oui c'est à peut près ça, tester le max d'options, modules en tout genre jusqu'à trouver une erreur, crash, fonctionnement anormal.
La précédente version avait des difficultés avec le décodage de l'unicode sur les sites exotiques (caractères chinois et compagnie), ce qui est normalement réglé pour la future version mais ça vaut toujours le coup de tester :)
Et évidemment sur pages avec du mauvais HTML, balises pas fermées etc… mais ça on en trouve partout :p