Une attaque CSRF est celle qui fait que les utilisateurs authentifiés effectuent des actions indésirables dans l'application Web avec laquelle ils sont authentifiés. Cela se fait via un site externe que l'utilisateur visite et qui déclenche ces actions.

Dans cet article, vous obtiendrez les informations requises de la demande afin de savoir ce que le site d'attaque doit faire pour envoyer des demandes 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 le faire ressembler davantage à une attaque du monde réel, où la victime ne le remarque pas. Notez que le fichier de code pour 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 Utilisateur @ Exemple.com En tant que victime:

Comment faire…

Tout d'abord, vous devez analyser la demande que vous souhaitez forcer la victime à faire. Pour ce faire, vous avez besoin de Burp Suite ou d'un autre proxy configuré dans le navigateur:

1. Connectez-vous à BodGeit en tant qu'un utilisateur et cliquez sur le nom d'utilisateur pour accéder au profil.
2. Faire un changement de mot de passe. Voyez à quoi ressemble la demande dans le proxy:

   Donc, c'est un POSTE demande à http: // 192.168.56.11 / Bodgeit / mot de passe.jsp, et n'a que le mot de passe et sa confirmation dans le corps.

3. Essayez de créer une page HTML très simple qui reproduit cette demande. Créer un fichier (nommez-le mot de passe-changement CSRF.html) avec le contenu suivant:
   
   
   
   
   
   
   
   
   
   
4. Maintenant, chargez ce fichier dans le même navigateur que votre session connectée:
5. 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.
6. 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 toujours peu probable qu'un utilisateur clique sur le Soumettre Vous pouvez l'automatiser et masquer les champs d'entrée afin que le contenu malveillant soit caché. Maintenant, faites une nouvelle page basée sur la précédente; appeler CSRF-Change-Password-Scrit.html:
   
   
   

   Une page complètement inoffensive

   
   Vous pouvez faire confiance à cette page.
   Rien de mal ne vous arrivera ni 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 est complètement chargée.

7. Si vous chargez cette page dans le même navigateur où vous avez une session BodGeit initiée, elle enverra automatiquement la demande et la page de profil de l'utilisateur s'affiche après cela. Dans la capture d'écran suivante, le navigateur DébogueurDéfinissez un point d'arrêt juste avant la demande de la demande:
8. Cette dernière tentative semble mieux 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 la victime verra le votre mot de passe a été changémessage, et cela soulèvera sûrement une alerte.
9. Vous pouvez encore améliorer la page d'attaque en lui faisant charger la réponse dans un cadre invisible dans la même page. Il existe de nombreuses façons de le faire; Un rapide et sale est de régler une taille 0 pour le cadre. Votre fichier ressemblerait à ceci:
   
   
   

   Une page complètement inoffensive

   
   Vous pouvez faire confiance à cette page.
   Rien de mal ne vous arrivera ni votre compte Bodgeit.
   
   Target = "Target_Frame">
   
   
   
   
   
   
   

   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.

10. Chargez la nouvelle page dans le navigateur où la session a été initiée. Cette capture d'écran montre à quoi ressemble la page lors de l'inspecture avec le navigateur Outils de développement: Notez que l'objet Iframe n'est qu'une ligne noire sur la page et, dans l'inspecteur, vous pouvez voir qu'il contient la page de profil de l'utilisateur Bodgeit.
11. Si vous analysez les communications réseau entreprises par votre page CSRF, vous pouvez voir qu'elle fait des demandes de modification du mot de passe Bodgeit:

Comment ça fonctionne…

Lorsque vous envoyez une demande d'un navigateur et que vous avez déjà un cookie appartenant au domaine cible stocké, le navigateur fixera le cookie à la demande avant son envoi. C'est ce qui rend les cookies aussi pratiques que les 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 attachera 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 lancée.

Si le serveur ne vérifie pas que les demandes qu'il reçoit proviennent réellement de l'application, elle permet à un site malveillant de passer des appels au nom des utilisateurs actifs légitimes qui visitent ce site malveillant tout en étant authentifié dans le domaine cible.

Dans un test de pénétration d'application Web, le premier code que vous avez utilisé, celui avec les deux champs de texte et le Soumettre bouton, peut être suffisant pour démontrer la présence d'un défaut de sécurité. Cependant, les tests de pénétration de l'application peuvent faire partie d'un autre engagement, comme un ingénierie sociale ou un exercice d'équipe rouge. Dans ce cas, des efforts supplémentaires seront nécessaires pour empêcher l'utilisateur de la 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 du gestionnaire d'événements. Vous avez également utilisé un iframe caché pour charger la réponse du changement de mot de passe, donc la victime ne voit jamais le message que son mot de passe a changé.

Si vous avez trouvé cet article intéressant, vous pouvez explorer Kali Linux Web Pénétration Test 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 Pénétration Test Cookbook - Deuxième édition Vous donne les compétences dont vous avez besoin pour couvrir chaque étape d'un test de pénétration - de la collecte d'informations sur le système et de l'application à l'identification des vulnérabilités grâce à des tests manuels.