La Cross-Site Request Forgery (CSRF)

La Cross-Site Request Forgery (CSRF) est une attaque assez grave, impliquant généralement une ingénierie sociale.
Pour faire simple il s’agit de demandes inter-sites contrefaites qui permettent de forcer l’utilisateur final à exécuter des actions non désirées sur une application web à laquelle il est authentifié.

Avertissement :
Utiliser les techniques présentées sur ce blog, sur des systèmes qui ne vous appartiennent pas est ILLEGAL et peut vous exposer à de lourdes sanctions.

Si vous souhaitez vous exercer, vous devez le faire sur un système qui vous appartient, ou avec un accord écrit du propriétaire.

Je ne pourrais en aucun cas être tenu pour responsable de vos actes.

Scénario

Un utilisateur se connecte à une application (par exemple un site bancaire).
L’attaquant envoie à cet utilisateur un courriel contenant un payload (la charge utile malveillante) : une URL spécialement conçue, un formulaire caché ou une image avec un code malveillant.
Lorsqu’il est exécuté (lorsque l’utilisateur clique sur un lien, charge une page ou une image), le payload demande à l’application que l’utilisateur soit déjà connecté, en exploitant la session active dans le navigateur pour obtenir l’autorisation.

Le pirate peut ensuite modifier de l’adresse électronique d’un utilisateur afin de pouvoir utiliser la fonction de réinitialisation du mot de passe d’une application basée sur le courrier électronique pour s’octroyer un accès.

Les payloads CSRF

Si l’application peut être mise à jour à l’aide de requêtes GET, le payload pourrait être intégrée dans une balise img.

<img src="https://[host]/change-password.php?newPassword=hackerpassword">

Envoi d’un payload via un formulaire automatique

Les payloads CSRF peuvent également être fournis à l’aide de formulaires web cachés qui soumettent automatiquement des données POST lorsqu’un utilisateur charge une page spécialement conçue envoyée par l’attaquant :

<html>
  <head>
    <title>Malicious web form</title>
  </head>
  <body onload="document.evil_bank_form.submit()">
    <form action="http://bank.com/transfer" method="POST" name="evil_bank_form" style="display: none;" target="hidden_results">
      <input type="text" name="amount" value="5000" />
      <input type="text" name="to_account" value="12345" />
    </form>
     <iframe name="hidden_results" style="display: none;"></iframe>
  </body>
</html>

Dans l’exemple ci-dessus, lorsqu’un utilisateur charge cette page web, le formulaire malveillant effectue un virement bancaire sur le compte de l’attaquant, en tirant parti de la session de navigation active de l’utilisateur avec la banque. Le formulaire a également une cible qui affiche les résultats dans une iframe cachée afin que l’utilisateur ne remarque pas la demande malveillante.

Générer un payload avec Burp

À des fins de test, Burp Suite peut générer automatiquement un payload CSRF de preuve de concept, mais vous devez vérifier qu’il n’y a pas de jeton unique dans la charge utile de test (par exemple un élément de formulaire avec une chaîne aléatoire). Il existe plusieurs façons de procéder :

  • Exécuter la charge utile deux fois pour voir si le serveur la rejette parce qu’il s’agit d’une demande en double ou expirée.
  • Supprimer ou modifier tout ce qui ressemble à un jeton dans les éléments de formulaire ou les paramètres GET et voir si la charge utile fonctionne toujours.
  • Remplacer la valeur du jeton par une chaîne de même longueur et voir si la charge utile fonctionne toujours.
  • Laissez la valeur du jeton en blanc et vérifiez si la charge utile fonctionne toujours.

En général, si l’une des actions ci-dessus provoque une erreur, l’application dispose de certaines protections anti-CSRF qui limitent l’exploitation. Les sessions peuvent également être configurées pour expirer rapidement, ce qui rend les attaques CSRF moins viables.

Trouver des CSRF

Les vulnérabilités du CSRF peuvent survenir lorsque les applications se basent uniquement sur des cookies HTTP pour identifier l’utilisateur qui a émis une requête particulière. Comme les navigateurs ajoutent automatiquement des cookies aux requêtes, quelle que soit l’origine de la requête, il est possible pour un attaquant de créer un site malveillant qui va crafter (forger) une requête inter-domaine vers l’application vulnérable.

Dans cet exemple, nous utiliserons le générateur de PoC CSRF de Burp pour nous aider à détourner le compte d’un utilisateur en modifiant ses coordonnées (l’adresse électronique associée au compte) sur une ancienne version vulnérable de GetBoo.

La version de GetBoo que nous utilisons est tirée du Broken Web Application Project de l’OWASP. Découvrez comment télécharger, installer et utiliser ce projet.

Burp Scanner est capable de localiser les problèmes potentiels de CSRF.

Le scanner identifie un certain nombre de conditions, notamment lorsqu’une application repose uniquement sur des cookies HTTP pour identifier l’utilisateur, qui font qu’une demande est vulnérable au CSRF.

Pour tester manuellement les vulnérabilités du CSRF, assurez-vous d’abord que Burp est correctement configuré avec votre navigateur.

  • Dans l’onglet Intercept, assurez-vous que Intercept is off.
  • Visitez l’application web que vous testez dans votre navigateur.
  • Assurez-vous que vous êtes authentifié à l’application web que vous testez.
    Dans cet exemple, vous pouvez vous connecter à l’aide des identifiants user:user.
  • Accédez à la page que vous testez.
  • Modifiez la valeur dans le(s) champ(s) que vous souhaitez modifier, dans ce cas Email.

    Dans cet exemple, nous ajouterons un numéro à l’e-mail.
  • Retournez dans Burp.
  • Dans l’onglet Intercept, assurez-vous que Intercept is on.
  • Soumettez la requête de manière à ce qu’elle soit saisie par Burp.
  • Dans l’onglet Proxy, cliquez avec le bouton droit de la souris sur la requête.
  • Allez dans Engagement tools et cliquez sur Generate CSRF PoC.

Vous pouvez également générer des PoC CSRF via le menu contextuel là où les requêtes HTTP sont affichées, comme dans Site map ou History.

  • Dans la fenêtre CSRF PoC generator, vous devez modifier la valeur de l’entrée fournie par l’utilisateur.
    Dans cet exemple, nous allons mettre newemail@malicious.com.
  • Cliquez sur Copy HTML.
  • Ouvrez un éditeur de texte et collez le HTML copié.
  • Enregistrez le fichier en tant que fichier HTML.
  • Dans l’onglet Intercept, assurez-vous que Intercept is off.
    Si nécessaire, reconnectez-vous à l’application.

Dans un premier temps, nous allons tester l’attaque sur le même compte.

  • Ouvrez le fichier HTML dans le même navigateur.

En fonction des options du CSRF PoC, vous pouvez avoir besoin de soumettre la demande ou elle peut être soumise automatiquement.

  • Dans ce cas, nous soumettons la demande manuellement : cliquez sur Submit request.

Si l’attaque a réussi et que les informations du compte ont été modifiées avec succès, cela sert de contrôle initial pour vérifier si l’attaque est possible.

  • Connectez-vous maintenant à l’application en utilisant un autre compte (dans cet exemple, le compte d’administration de l’application).
  • Une fois que vous êtes connecté, effectuez à nouveau l’attaque en ouvrant le fichier dans le même navigateur.

L’attaque est réussie si les informations du compte dans l’application web ont été altérées.

Une attaque réussie montre que l’application web est vulnérable au CSRF.

Pour que l’attaque puisse se dérouler dans un environnement réel, la victime doit accéder à une page sous le contrôle de l’attaquant tout en étant authentifiée.

Dans notre exemple, un nouveau mot de passe peut être défini pour le compte à l’aide de l’adresse électronique.
De cette façon, un attaquant pourrait obtenir la pleine propriété du compte.


Dans un prochain article nous verrons la soeur de la CSRF, la Server-side request forgery (SSRF).

En attendant, retrouvez tous nos articles : Hacking, Dev, Sécu.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *