web-dev-qa-db-fra.com

Protection CSRF avec jetons Web JSON

J'ai lu que lors de l'utilisation de JWT, il n'est pas nécessaire de se protéger contre les attaques CRSF, par exemple: " étant donné que vous ne vous fiez pas aux cookies, vous n'avez pas besoin de vous protéger contre les requêtes entre sites }".

Cependant, quelque chose que je ne comprends pas: si je stocke le jeton dans localStorage (comme on me l’avait conseillé sur un tutoriel du même site Web ), ce qui empêche un attaquant de créer une requête malveillante en lisant mon localStorage au lieu de mes cookies? 

Comme il a été généré côté serveur, je ne comprends pas comment utiliser un jeton pour une requête client sans qu'il soit stocké quelque part sur le client.

local-storagecsrfjwtauth0
30
JulienD

À proprement parler, oui, tout ce qui est stocké dans le stockage local/de session (que j'appellerai le stockage HTML5) pourrait être volé lors d'une attaque par script intersite (XSS). Voir cet article .

Il y a cependant beaucoup d'éléments mobiles à prendre en compte. 

Tout d'abord, il existe des différences subtiles dans la manière dont le stockage HTML5 et les cookies sont définis en ce qui concerne l'accès JavaScript. 

Le stockage HTML5 est:

  • divisé entre http et https. Un élément stocké dans http://example.com stockage HTML5 n'est pas accessible par JavaScript s'exécutant sur https://example.com.
  • divisé entre sous-domaines. Un élément stocké dans http://example.com stockage HTML5 n'est pas accessible par JavaScript s'exécutant sur http://sub.example.com (vous pouvez toutefois faire quelques astuces pour résoudre ce problème).

Les cookies sont plus volumineux:

  • Un cookie avec un domaine example.com ira à la fois à http://example.com et à https://example.comsauf si il possède l'attribut secure, auquel cas il ne sera envoyé qu'à https.
  • Un cookie non envoyé avec un domaine explicite ne sera renvoyé qu'au domaine exact qui l'a envoyé. Si le domaine est explicitement défini sur example.com, il sera envoyé à la fois à example.com et à sub.example.com. (Ceci est la partie la plus déroutante du cookie "spec", malheureusement, voir cet article ).
  • Un cookie peut être lu par JavaScript s'il est exécuté sur une page avec un domaine correspondant (et en respectant l'indicateur de cookie secure) sauf si le cookie a l'attribut httpOnly, auquel cas JavaScript ne pourra pas le lire.

Deuxièmement, comme les cookies sont marqués avec un domaine, lorsqu'une demande est faite à un serveur, le navigateur envoie des cookies tout-seuls avec un domaine correspondant, quel que soit le domaine de la page à l'origine de la demande.

La dernière partie concerne la manière dont une attaque CSRF est réalisée (la politique de même origine n’aide que beaucoup). La page OWASP sur CSRF est une bonne ressource pour apprendre le fonctionnement de ce type d’attaques.

La raison pour laquelle un jeton d’authentification est stocké dans le stockage local et ajoutée manuellement à chaque requête protégée contre CSRF est la clé Word: manual. Etant donné que le navigateur n'envoie pas automatiquement ce jeton d'authentification, si je visite evil.com et parvient à envoyer un POST http://example.com/delete-my-account, il ne pourra pas envoyer mon jeton d'authn, la demande est donc ignorée.

Compte tenu de ce qui précède, l’utilisation d’un cookie ou du stockage HTML5 devient une série de compromis:

Stocker le jeton d’authentification dans le stockage HTML5 signifie:

  • (-) Risque de vol lors d’une attaque XSS.
  • (+) Fournit une protection CSRF.
  • (-) Doit modifier manuellement chaque requête envoyée au serveur, en vous limitant aux applications Web SPA (par exemple, AngularJs).

D'autre part, si vous stockez le jeton d'authn dans un cookie marqué httpOnlyetsecure, alors:

  • (+) Le jeton d'authn ne peut pas être volé par XSS.
  • (-) Vous devrez assurer vous-même la protection de la CSRF. La mise en œuvre de la protection CSRF est plus facile dans certains cadres que dans d'autres.

Quelle option est la meilleure dépend de vos besoins. 

  • Votre jeton d'authentification protège-t-il quoi que ce soit avec de l'argent? Vous voudrez probablement l'option cookie httpOnlysecure.
  • Le niveau d'effort requis pour mettre en œuvre la protection CSRF ne vaut-il pas les actifs qu'il protège? Ensuite, le stockage HTML5 pourrait être le bon endroit.
75
kuporific

Lorsque vous utilisez une authentification par jeton, vous devez associer manuellement le jeton à la demande. Contrairement aux cookies, les jetons ne sont pas définis automatiquement par le navigateur et ne sont donc pas susceptibles d'attaques csrf.

Bien que cette approche soit à l'abri d'attaques csrf, elle est susceptible d'attaques xss.

Une amélioration minimale consisterait à utiliser session storage au lieu de local storage car les données session storage sont purgées une fois que l'utilisateur a fermé l'onglet/le navigateur.

1
senjin.hajrulahovic