Bonjour les amis, aujourd'hui je vais vous montrer les étapes de détection d'une vulnérabilité que j'ai rencontrée dans les tests de sécurité des applications Web dans mon projet nommé Saka Reflected XSS (JS Variable) et l'exploitation de cette vulnérabilité.

Qu'est-ce que XSS

Vous pouvez trouver des informations détaillées sur la vulnérabilité XSS dans l'article ci-dessous.

Exécution de l'application

Docker

docker pull erdemstar/saka:reflected-xss-js-variable
docker run -d -p 80:80 erdemstar/saka:reflected-xss-js-variable

git clone https://github.com/ErdemStar/Saka
cd reflected-xss-js-variable
- mouse click on reflected-xss-input.sln
- devenv reflected-xss-input.sln (CMD)

Lorsque nous ouvrons l'application pour la première fois, une page comme celle ci-dessous nous accueille. En appuyant sur le bouton Attack de la page, nous sommes dirigés vers la partie que nous allons tester.

Lorsque nous arrivons à la page d'attaque, nous sommes confrontés à une page où les informations de nom sont extraites de l'utilisateur. Lorsque nous écrivons un nom dans ce champ et que nous l'envoyons, nous obtenons le résultat suivant.

Pour regarder de plus près l'application, il serait utile de voir les requêtes entrantes et sortantes via le navigateur.

Notes mentales

• La valeur reçue de l'utilisateur est conservée dans le paramètre name et envoyée à l'aide de GET HTTP Verb.
• L'application affiche la valeur qu'elle reçoit de l'utilisateur en utilisant les lignes 72–73–74 de l'image partagée ci-dessus. L'application affiche les données à l'utilisateur dans le champ JS.

Après avoir obtenu suffisamment d'informations sur l'application, nous ajoutons quelques caractères à interpréter par le navigateur à la valeur du nom que nous enverrons afin d'exploiter la vulnérabilité XSS.

Lorsque nous vérifions le contenu de la réponse entrante, il est entendu que l'application reflète la valeur du nom que nous avons reçue sans aucun contrôle de sécurité.

Ici, lorsque les données reçues de l'utilisateur sont ajoutées dans la balise script, elles peuvent être exploitées avec 2 méthodes différentes.

1-Méthode (Injection HTML)

Lorsque les 73 lignes renvoyées dans Response sont examinées, l'application utilise indirectement la fonctionnalité Javascript inner.html au lieu d'ajouter et d'afficher les données qu'elle reçoit de l'utilisateur directement en HTML. Ici, une attaque XSS peut être effectuée lorsqu'une requête comme celle ci-dessous est émise.

2-Méthode (contournement JS)

Après avoir examiné 73 lignes, une requête avec un format de charge similaire à celui ci-dessous peut être envoyée et différentes commandes Javascript peuvent être exécutées dans la balise de script.

<context>";//<payload>

A ce stade, la commande JS a été rendue exécutable directement en faisant une simple requête comme suit.

Merci d'avoir lu mon article, j'espère qu'il vous a été utile. Ci-dessous, je laisse les liens de mes autres concepts qui pourraient vous être utiles.

Cliquez ici pour voir mes autres articles sur les vulnérabilités Web. Lien