ASP.NET MVC - Attaque CSRF

Il y a un type d'attaque auquel nous sommes sujets et que nous négligeons souvent, c'est le Contrefaçon de requête intersites ou alors CSRF, celui-ci est responsable de tromper notre application pour qu'elle reçoive des données qui ne proviennent pas du domaine où elle est hébergée.
Ce type d'attaque est assez préjudiciable car il amène un utilisateur qui a été trompé à utiliser son authentification pour entrer des données dans notre base de données, imaginez qu'avec une attaque de ce type un utilisateur administratif ou peut-être de fausses nouvelles soit réussi à entrer dans notre section d'actualités .
Comme nous l'avons expliqué, cette attaque trompe notre application pour qu'elle reçoive des données qui ne viennent pas d'elle-même, pour cela elle profite de la façon dont les protocoles fonctionnent comme HTTP et ses différentes méthodes, un attaquant peut ainsi créer un formulaire et pointer sur notre contrôleur.
Pour illustrer cette attaque, regardons le contrôleur suivant qui est vulnérable à ce type d'attaque :

Ici, nous pouvons voir comment nous obtenons les données directement depuis notre formulaire et ce n'est pas mal, le seul problème est que nous ne disons pas à notre application qu'elle doit valider son origine, avec cela un attaquant peut générer un script comme celui-ci :

AGRANDIR

Ici, il est clair ce qui se passe, lors du chargement de cette page, le formulaire qui pointe vers un enregistrement spécifique dans la base de données est envoyé, ce formulaire pointe vers un contrôleur valide, donc si un utilisateur authentifié est dirigé vers cette page, nous sommes probablement dans un peu d'un lien.
Malgré son fatalisme, cette attaque est évitable, pour cela nous n'avons qu'à faire quelques validations qui garantissent que les données reçues proviennent de notre application, pour cela nous pouvons utiliser certaines de ces techniques :
Référence de domaineCela consiste à vérifier de quel domaine provient la demande, nous garantissons ainsi qu'il s'agit uniquement du domaine où notre application est hébergée, le seul problème ou inconvénient est que si nous migrons notre application de domaine, nous devrons peut-être reconstruire la validation au cas où nous n'avons pas rendu dynamique. Il est également possible de faire une fausse référence en profitant de vulnérabilités applicatives telles que Adobe Flash.
Jeton généréAvec cette option, ce que nous faisons, c'est que dans notre formulaire un jeton qui est unique par utilisateur, donc notre application lors de la réception des formulaires valide que le jeton est le même, de cette façon elle permet d'accepter ou non les données. C'est l'option la plus largement utilisée car elle est très facile à mettre en œuvre et présente peu ou pas d'inconvénients.
Dans le cas du jeton généré ASP.NET MVC contient quelques méthodes qui peuvent nous aider, la principale est @ Html.AntiForgeryToken () qui génère la clé secrète par laquelle notre application peut valider les formulaires.
Nous voyons alors qu'il y a plus de domaines que nous ne le pensons et que nous devons prendre en compte dans nos applications, nous devons donc nous informer et être conscients de la manière dont les attaques se produisent afin de trouver des moyens de les éviter.