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 (Referer) 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-referer
docker run -d -p 80:80 erdemstar/saka:reflected-xss-referer

git clone https://github.com/ErdemStar/Saka
cd reflected-xss-referer
- 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 Attaque, les champs de nom et de message sont disponibles. Lorsque ces champs sont remplis et que la demande est envoyée, il est entendu qu'il n'y a pas de changement dans la page.

Puisqu'il n'y a pas de changement du côté de l'interface utilisateur, vérifions les requêtes GET et POST et regardons de plus près.

Il a été entendu que GET Request est utilisé pour récupérer directement la page d'attaque sans recevoir aucune donnée de l'utilisateur.

Bien que l'on pense que POST Request est utilisé pour envoyer les informations de nom et de message qu'il a prises de l'utilisateur, lorsque la partie du corps est vérifiée, on voit qu'elle n'a pas un tel but, elle envoie uniquement un champ nommé referer au arrière-plan.

La requête POST envoyée à l'application est créée lorsque le bouton du formulaire côté UI est cliqué. Pour regarder de plus près, la réponse avec GET Request doit être examinée.

Lorsque la balise <form> de la réponse obtenue avec la requête GET est examinée, on constate que les parties nom et message sont vides et que l'existence d'une entrée nommée référent et la valeur qui lui est attribuée ont été détectées.

Il a été entendu que la raison pour laquelle l'élément d'entrée n'est pas visible depuis l'interface utilisateur est due au paramètre de type=hidden .

Regardez la requête GET, il peut être vérifié si le "http://localhost/" La valeur attribuée au référent dans la réponse provient de la requête comme suit.

En regardant de plus près le champ Referer dans la requête GET, la présence d'une réflexion d'entrée est détectée en regardant la réponse.

Il a été observé que le même résultat n'est pas obtenu avec la requête POST, qui est similaire à la requête faite dans la requête GET.

Notes mentales

• L'application n'utilise pas les informations de nom et de message reçues de l'utilisateur via le formulaire.
• Lorsqu'une requête est envoyée au point de terminaison /Home/Attack avec GET, les données du champ Header Referrer de la requête correspondante sont également reflétées dans l' entrée de référence dans la réponse.

Après avoir obtenu suffisamment d'informations sur l'application, nous ajoutons quelques caractères à interpréter par le navigateur à la valeur du Referer 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 la candidature reflète la valeur du Référent reçue de notre part sans aucun contrôle de sécurité.

Après avoir obtenu autant d'informations sur le comportement de l'application, lorsque nous envoyons une requête comme celle ci-dessous au champ Referer , nous exécutons le scénario XSS réfléchi sur l'application.

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