• 6 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 29/03/2023

Empêchez les attaques par falsification de requête intersite

Qu'est-ce qu'une attaque par falsification de requête intersite (XSRF/CSRF) ?

Une attaque par falsification de requête intersite (XSRF or CSRF) est une attaque fréquente consistant pour une application malveillante à tirer parti des interactions entre le navigateur client et une application Web qui fait confiance à ce navigateur. Ces attaques sont possibles, car les navigateurs envoient automatiquement certains types de tokens d'authentification à chaque requête à un site Web. Le pirate tire donc profit de la session authentifiée de l'utilisateur auprès de l'application en question.

Imaginez le scénario suivant :

  1. Un utilisateur se connecte sur www.mabanque.com via une authentification par formulaire. Le serveur l'authentifie et envoie une réponse contenant notamment un cookie d'authentification. Le site est désormais vulnérable, car il fait confiance à toutes les requêtes qu'il reçoit contenant un cookie d'authentification valide.

  2. L'utilisateur consulte ensuite un site malveillant, www.sites-mechants.com. Ce site contient un formulaire HTML se présentant comme suit :

<h1>Félicitations ! Vous avez gagné !</h1>
<form action="http://www.mabanque.com/api/compte" method="post">
<input type="hidden" name="Transaction" value="retrait">
<input type="hidden" name="Montant" value="1000000">
<input type="submit" value="Cliquez pour récupérer votre prix !">
</form>

Vous remarquerez que l'attribut action du formulaire cible le site vulnérable et pas le site malveillant. C'est la partie intersite d'une attaque CSRF.

3. L'utilisateur clique sur le bouton. Le navigateur traite la requête et inclut automatiquement le cookie d'authentification pour le domaine demandé, www.mabanque.com.

4. La requête est exécutée sur le serveur de www.mabanque.com avec le contexte de l'utilisateur et peut réaliser n'importe quelle action qu'un utilisateur authentifié est autorisé à effectuer.

Le site n'est pas obligé de faire en sorte que l'utilisateur clique pour soumettre un formulaire. Il peut aussi :

  • exécuter un script qui soumet automatiquement le formulaire ;

  • envoyer le contenu du formulaire sous forme de requête AJAX ;

  • masquer le formulaire à l'aide de code CSS.

Dans ces différents scénarios, l'utilisateur n'aurait ni besoin d'accomplir une action ni de saisir quoi que ce soit. L'attaque serait directement déclenchée par la visite sur le site malveillant.

Certains développeurs pensent que l'utilisation du protocole HTTPS les protège de ces attaques, mais il n'en est rien. Un site malveillant peut envoyer une requête à https://www.mabanque.com/ comme à http://www.mabanque.com/.

Les applications Web qui utilisent des cookies pour l'authentification sont vulnérables aux attaques CSRF pour diverses raisons :

  • Les navigateurs stockent les cookies émis par une application Web.

  • Parmi ces cookies se trouvent les cookies de session des utilisateurs authentifiés.

  • Les navigateurs envoient à l'application Web tous les cookies associés à un domaine à chaque requête, quelle que soit la méthode utilisée pour la générer.

Toutefois, les attaques CSRF ne se limitent pas à l'exploitation des cookies. Une autre vulnérabilité concerne les authentifications de type basic et digest. Dès qu'un utilisateur s'authentifie via l'une de ces deux méthodes, le navigateur envoie automatiquement les identifiants jusqu'à la fin de la session.

Pour se protéger des vulnérabilités CSRF, voici quelques précautions que peuvent prendre les utilisateurs finaux :

  • Se déconnecter des applications Web lorsqu'ils ont fini de les utiliser.

  • Supprimer régulièrement les cookies de leur navigateur.

Toutefois, les attaques CSRF sont davantage liées à un problème de l'application Web qu'à un problème de l'utilisateur final.

Protégez vos sites contre les attaques XSRF/CSRF

Heureusement, il est facile d'empêcher ce type d'attaques. Dès que vous créez des Razor Pages (l'objet de ce cours), vous n'avez même plus besoin d'écrire de code pour créer des mécanismes de validation de tokens anti-falsification. En effet, toutes les Razor Pages que vous codez en .NET intègrent automatiquement la génération et la validation de tokens anti-falsification.

En résumé 

Dans ce chapitre, nous avons vu les points suivants :

  1. Les attaques par falsification de requête intersite (XSRF) exploitent la relation de confiance qui lie un client à un serveur en utilisant les cookies et autres tokens pour usurper des sessions utilisateur authentifiées.

  2. En tant que développeur, vous pouvez facilement empêcher les attaques XSRF en codant des Razor Pages, car elles incluent automatiquement la génération et la validation de tokens anti-falsification.

Nous allons maintenant parler des redirections ouvertes. Elles sont souvent utilisées lors des attaques XSS et XSRF pour ingénieusement  intercepter les données confidentielles des utilisateurs.

Exemple de certificat de réussite
Exemple de certificat de réussite