29 Mar 2016

Contrer la faille CSRF dans les applications Web API

Comme évoqué dans ce premier article, la faille de sécurité de type Cross-Site Request Forgery est relativement facile à éviter sur des applications ASP.NET MVC avec le moteur de rendu Razor. L’appel à un helper HTML et à un attribut MVC lors de la validation du formulaire permettent de s’assurer que la validation du formulaire est bien réalisée par l’utilisateur authentifié lui-même.

Cette mécanique devient un peu plus compliquée à gérer pour les applications “single page” n’utilisant pas le moteur de rendu Razor, et faisant appel à des controllers WebApi et non pas MVC. L’exemple suivant s’appuie également sur le framework Angular Js, mais il pourrait être mis en œuvre sur une application ne l’utilisant pas. La suite de l’article s’inspire de l’article suivant, en complétant certains points essentiels.

2 classes principales sont à ajouter :

  • celle qui permet de créer les tokens
  • celle qui permet de vérifier les tokens

La création des tokens va se faire grâce à un helper HTML appelé dans le layout de l’application (via une directive Angular JS) :

Une fois ces éléments ajoutés, un token est alors généré dans la page et un autre dans les cookies de l’utilisateur. Il reste donc à vérifier la cohérence de ces tokens lors de l’appel aux controllers, à l’aide d’un filtre, comme on le ferait dans un controller MVC.

Le principe du filtre est simple : il va récupérer le token du cookie, celui du formulaire, et vérifier leur concordance en se basant toujours sur la classe System.Web.Helpers.AntiForgery du framework :

Une fois ces deux classes et les quelques éléments côté client ajoutés au projet, il suffit alors d’appeler le filtre sur les actions des controllers WebApi nécessitant la vérification du token, c’est à dire les méthodes de soumissions de formulaire derrière une authentification :

Enfin, un dernier point, attention aux applications load-balancées : afin de garantir la cohérence des deux tokens sur les x serveurs de la ferme, il est nécessaire d’insérer dans les web.config un même machinekey à l’aide du serveur IIS. Vous pourriez sinon avoir quelques surprises si les tokens sont générés sur un serveur A, et validés sur un serveur B !

En résumé :

Antiforgery token - Sans                  Antiforgery token - Avec

 

Share