Phenquestions
Dans cet article, vous obtiendrez les informations nécessaires de l'application afin de savoir ce que le site attaquant doit faire pour envoyer des requêtes valides au serveur vulnérable. Ensuite, vous créerez une page qui simule les demandes légitimes et incite l'utilisateur à visiter cette page tout en étant authentifié. Vous ferez également quelques itérations sur la preuve de concept de base pour la faire ressembler davantage à une attaque du monde réel, où la victime ne le remarque pas. Notez que le fichier de code de cet article peut être trouvé sur le github de l'auteur.
Se préparer
Vous aurez besoin d'un compte utilisateur valide dans BodgeIt pour cet article. Cet article utilise [email protégé] en tant que victime :
Comment faire…
Tout d'abord, vous devez analyser la demande que vous voulez forcer la victime à faire. Pour ce faire, vous avez besoin de Burp Suite ou d'un autre proxy configuré dans le navigateur :
- Connectez-vous à BodgeIt en tant qu'utilisateur et cliquez sur le nom d'utilisateur pour accéder au profil.
- Faire un changement de mot de passe. Voyez à quoi ressemble la requête dans le proxy :
Alors, c'est un
PUBLIERdemande àhttp://192.168.56.11/bodgeit/mot de passe.jsp,et n'a que le mot de passe et sa confirmation dans le corps. - Essayez de créer une page HTML très simple qui réplique cette requête. Créez un fichier (nommez-le
csrf-changer-mot de passe.html) avec le contenu suivant :
- Maintenant, chargez ce fichier dans le même navigateur que votre session de connexion :
- Cliquez sur soumettre et vous serez redirigé vers la page de profil de l'utilisateur. Il vous dira que le mot de passe a été mis à jour avec succès.
- Bien que cela prouve le point, un site externe (ou une page HTML locale comme dans ce cas) peut exécuter une demande de changement de mot de passe sur l'application. Il est encore peu probable qu'un utilisateur clique sur le Soumettre Vous pouvez l'automatiser et masquer les champs de saisie afin que le contenu malveillant soit masqué. Maintenant, créez une nouvelle page basée sur la précédente ; appeler
csrf-change-password-scripted.html:Une page totalement inoffensive
Vous pouvez faire confiance à cette page.
Rien de grave ne va vous arriver à vous ou à votre compte BodgeIt.
Cette fois, le formulaire a un paramètre ID et il y a un script sur la page qui soumettra son contenu lorsque la page sera complètement chargée.
- Si vous chargez cette page dans le même navigateur où vous avez lancé une session BodgeIt, il enverra automatiquement la demande et la page de profil de l'utilisateur s'affichera après cela. Dans la capture d'écran suivante, le navigateur Débogueurdéfinir un point d'arrêt juste avant que la demande ne soit faite :
- Cette dernière tentative est meilleure du point de vue d'un attaquant. Vous n'avez besoin que de la victime pour charger la page et la demande sera envoyée automatiquement, mais alors la victime verra le votre mot de passe a été changémessage, et cela déclenchera sûrement une alerte.
- Vous pouvez encore améliorer la page attaquante en lui faisant charger la réponse dans un cadre invisible à l'intérieur de la même page. Il existe de nombreuses façons de le faire ; un rapide et sale consiste à définir une taille 0 pour le cadre. Votre fichier ressemblerait à ceci :
Une page totalement inoffensive
Vous pouvez faire confiance à cette page.
Rien de grave ne va vous arriver à vous ou à votre compte BodgeIt.
Remarquez comment la propriété cible du formulaire est l'iframe défini juste en dessous et que ce cadre a 0% de hauteur et de largeur.
- Chargez la nouvelle page dans le navigateur où la session a été initiée. Cette capture d'écran montre à quoi ressemble la page lorsqu'elle est inspectée avec le navigateur Outils de développement:
Notez que l'objet iframe n'est qu'une ligne noire sur la page et, dans Inspector, vous pouvez voir qu'il contient la page de profil de l'utilisateur BodgeIt. - Si vous analysez les communications réseau effectuées par votre page CSRF, vous pouvez voir qu'elle demande en fait de modifier le mot de passe BodgeIt :
Comment ça fonctionne…
Lorsque vous envoyez une demande à partir d'un navigateur et qu'un cookie appartenant au domaine cible est déjà stocké, le navigateur attache le cookie à la demande avant qu'elle ne soit envoyée. C'est ce qui rend les cookies si pratiques comme identifiants de session, mais cette caractéristique du fonctionnement de HTTP est aussi ce qui le rend vulnérable à une attaque comme celle que vous avez vue dans cet article.
Lorsque vous chargez une page dans le même navigateur, où vous avez une session active dans une application, le navigateur attache automatiquement le cookie de session à cette demande. Cela se produit même s'il s'agit d'un onglet ou d'une fenêtre différent, et cette page fait une demande au domaine où la session est initiée.
Si le serveur ne vérifie pas que les demandes qu'il reçoit proviennent réellement de l'application, il permet à un site malveillant de passer des appels au nom d'utilisateurs actifs légitimes qui visitent ce site malveillant tout en étant authentifiés auprès du domaine cible.
Dans un test d'intrusion d'application Web, le premier code que vous avez utilisé, celui avec les deux champs de texte et le Soumettre bouton, peut suffire à démontrer la présence d'une faille de sécurité. Cependant, les tests d'intrusion de l'application peuvent faire partie d'un autre engagement, tel qu'un exercice d'ingénierie sociale ou d'équipe rouge. Dans ce cas, des efforts supplémentaires seront nécessaires pour empêcher l'utilisateur victime de soupçonner que quelque chose se passe.
Dans cet article, vous avez utilisé JavaScript pour automatiser l'envoi de la demande en définissant l'événement onload sur la page et en exécutant la méthode de soumission du formulaire dans la fonction de gestionnaire d'événements. Vous avez également utilisé un iframe masqué pour charger la réponse au changement de mot de passe, de sorte que la victime ne voit jamais le message indiquant que son mot de passe a changé.
Si vous avez trouvé cet article intéressant, vous pouvez explorer Kali Linux Web Penetration Testing Cookbook - Deuxième édition pour découvrir les vulnérabilités Web les plus courantes et les empêcher de devenir une menace pour la sécurité de votre site. Kali Linux Web Penetration Testing Cookbook - Deuxième édition vous donne les compétences dont vous avez besoin pour couvrir chaque étape d'un test d'intrusion - de la collecte d'informations sur le système et l'application à l'identification des vulnérabilités via des tests manuels.
