Falsification de requêtes intersites (CSRF)

Une attaque CSRF oblige un utilisateur authentifié (victime) à envoyer une requête HTTP falsifiée, y compris le cookie de session de la victime à une application Web vulnérable, ce qui permet à l'attaquant de forcer le navigateur de la victime à générer une requête de telle sorte que l'application vulnérable perçoit comme des requêtes légitimes de la victime.

Comprenons les agents de menace, les vecteurs d'attaque, la faiblesse de la sécurité, l'impact technique et les impacts commerciaux de cette faille à l'aide d'un diagramme simple.

Exemple

Voici un exemple classique de CSRF -

Step 1 - Disons que l'application vulnérable envoie une demande de changement d'état sous forme de texte brut sans aucun cryptage.

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 - Maintenant, le pirate construit une demande qui transfère de l'argent du compte de la victime vers le compte de l'attaquant en incorporant la demande dans une image qui est stockée sur divers sites sous le contrôle de l'attaquant -

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

Mains sur

Step 1- Réalisons une falsification CSRF en intégrant un script Java dans une image. L'instantané du problème est répertorié ci-dessous.

Step 2 - Nous devons maintenant simuler le transfert dans une image 1x1 et faire en sorte que la victime clique dessus.

Step 3 - Lors de la soumission du message, le message s'affiche comme indiqué ci-dessous.

Step 4- Maintenant, si la victime clique sur l'URL suivante, le transfert est exécuté, ce qui peut être trouvé en interceptant l'action de l'utilisateur à l'aide de burp suite. Nous pouvons voir le transfert en le repérant dans Get message comme indiqué ci-dessous -

Step 5 - Maintenant, en cliquant sur Actualiser, la marque de fin de leçon s'affiche.

Mécanismes préventifs

  • CSRF peut être évité en créant un jeton unique dans un champ caché qui serait envoyé dans le corps de la requête HTTP plutôt que dans une URL, qui est plus sujette à l'exposition.

  • Forcer l'utilisateur à s'authentifier de nouveau ou prouver qu'il est un utilisateur afin de protéger CSRF. Par exemple, CAPTCHA.