Où stocker JWT dans le navigateur? Comment se protéger contre CSRF?

je connais l'authentification basée sur les cookies. SSL et HttpOnly flag peuvent être appliqués pour protéger L'authentification basée sur les cookies de MITM et XSS. Toutefois, des mesures plus spéciales devront être prises pour la protéger de la FCRSS. Ils sont juste un peu compliqué. ( référence )

récemment, j'ai découvert que JSON Web Token(JWT) est une solution d'authentification très intéressante. Je connais les trucs sur l'encodage, le décodage et la vérification de JWT. Cependant, Je ne comprends pas pourquoi certains sites web/tutoriels ne disent pas besoin de protection CSRF si JWT est utilisé. J'ai beaucoup lu et j'essaie de résumer les problèmes ci-dessous. Je veux juste que quelqu'un puisse donner une vue d'ensemble de JWT et clarifier les concepts que j'ai mal compris à propos de JWT.

  1. si la JWT est stockée dans un cookie, je pense que c'est la même chose que l'authentification basée sur un cookie, sauf que le serveur n'a pas besoin de sessions pour vérifier le cookie/token. Il y a encore risque lié au FCRR si aucune mesure spéciale n'est mise en œuvre. JWT n'est pas stocké dans cookie?

  2. si le JWT est stocké dans un stockage local/sessionStorage, alors aucun cookie n'a donc pas besoin de se protéger contre le CRSF. La question Est de savoir comment envoyer la JWT au serveur. J'ai trouvé ici suggère d'utiliser jQuery pour envoyer le JWT par l'en-tête HTTP des requêtes ajax. Donc, seules les requêtes ajax peuvent faire l'authentification?

  3. aussi, j'ai trouvé un de plus blog montre à utiliser" en-tête D'autorisation "et" porteur " pour envoyer le JWT. Je ne comprends pas la méthode dont parle le blog. Quelqu'un pourrait-il expliquer plus sur "en-tête d'Autorisation" et "Porteur"? Est-ce que cela rend le JWT transmis par l'en-tête HTTP de toutes les requêtes? Si oui, que diriez-CSRF?

89
demandé sur MvdD 2014-11-21 20:44:16

2 réponses

Les tokens

JWT sont populaires car ils sont utilisés comme format de token par défaut dans les nouveaux protocoles d'autorisation et d'authentification comme OAuth 2.0 et OpenID Connect .

lorsque le token est stocké dans un cookie, le navigateur l'envoie automatiquement avec chaque requête vers le même domaine et cela reste vulnérable aux attaques CSRF.

L'authentification au porteur est l'un des les schémas d'authentification définis dans HTTP. Cela signifie essentiellement que YOU colle le jeton (JWT) dans l'en-tête HTTP D'autorisation d'une requête. Le navigateur va NOT le faire pour vous automatiquement, il n'est donc pas adapté pour protéger votre site web. Comme le navigateur n'ajoute pas automatiquement l'en-tête à votre demande, il n'est pas vulnérable à une attaque CSRF, qui dépend de vos informations d'authentification étant soumis automatiquement au domaine original.

le schéma porteur est souvent utilisé pour protéger les API web (Services de repos) qui sont consommés via les appels AJAX ou des clients mobiles.

40
répondu MvdD 2015-12-14 05:23:19

nous avons besoin de stocker le JWT sur l'ordinateur client. Si nous le stockons dans un stockage local/SessionStorage alors il peut être facilement saisi par une attaque XSS. Si nous le stockons dans des cookies, alors un hacker peut l'utiliser (sans le lire) dans une attaque CSRF et imiter l'utilisateur et contacter notre API et envoyer des requêtes pour faire des actions ou obtenir des informations au nom d'un utilisateur.

mais il ya plusieurs façons de sécuriser la JWT dans les cookies pour ne pas être volé facilement (mais il ya encore quelques techniques avancées pour les voler). Mais si vous voulez utiliser LocalStorage/SessionStorage, alors vous pouvez y accéder par une simple attaque XSS.

donc pour résoudre le problème CSRF, j'utilise des Cookies doubles soumettre dans ma demande.

Double Soumettre Des Cookies Méthode

  1. stockez JWT dans un cookie HttpOnly et utilisez-le en mode sécurisé pour transférer sur HTTPS.

  2. La plupart des attaques CSRF ont un en-tête origine ou referrer différent avec votre hôte d'origine dans leurs requêtes. Donc, vérifiez si vous avez l'un d'eux dans l'en-tête, sont-ils provenant de votre domaine ou non! Si pas de les rejeter. Si l'origine et le referrer ne sont pas disponibles dans la demande alors pas de soucis. Vous pouvez vous fier au résultat de la validation de l'en-tête X-XSRF-TOKEN que j'expliquerai à l'étape suivante.

  3. alors que le navigateur fournira automatiquement vos cookies pour le domaine de la demande, il y a une limitation utile: le code JavaScript qui s'exécute sur un site web ne peut pas lire les cookies d'autres sites web. Nous pouvons nous en servir pour créer notre solution CSRF. Pour empêcher les attaques CSRF, nous devons créer un cookie Javascript lisible supplémentaire qui est appelé: XSRF-TOKEN. Ce cookie doit être créé lorsque l'utilisateur est connecté et doit contenir un hasard, onu-deviner chaîne. Nous enregistrons également ce nombre dans la JWT elle-même comme une réclamation privée. Chacun lorsque L'application JavaScript veut faire une requête, elle devra lire ce token et l'envoyer dans un en-tête HTTP personnalisé. Comme ces opérations (lecture du cookie, définition de l'en-tête) ne peuvent être effectuées que sur le même domaine de L'application JavaScript, nous pouvons savoir que cela est fait par un utilisateur réel qui utilise notre application JavaScript.

Angular JS rend votre vie plus facile

heureusement, j'utilise Angular JS dans notre plate-forme et les paquets angulaires l'approche de jeton CSRF, ce qui rend plus simple pour nous de mettre en œuvre. Pour chaque requête que notre application angulaire fait du serveur, le service $http angulaire fera ces choses automatiquement:

  • recherchez un cookie nommé XSRF-TOKEN sur le domaine courant.
  • si ce cookie est trouvé, il lit la valeur et l'ajoute à la requête en tant qu'en-tête X-XSRF-TOKEN.

ainsi l'implémentation côté client est gérée pour vous, automatiquement! Nous avons juste besoin de configurer un cookie nommé XSRF-TOKEN sur le domaine courant côté serveur et lorsque notre API a reçu un appel du client, il doit vérifier l'en-tête X-XSRF-TOKEN et le comparer avec le XSRF-TOKEN dans le JWT. Si elles correspondent, alors l'utilisateur est réel. Sinon, c'est un faux demande et vous pouvez l'ignorer. Cette méthode s'inspire de la méthode" Double Submit Cookie".

Attention

en réalité, vous êtes toujours susceptible à XSS, c'est juste que l'attaquant ne peut pas vous voler JWT token pour une utilisation ultérieure, mais il peut quand même faire des requêtes pour le compte de vos utilisateurs en utilisant XSS.

que vous stockiez votre JWT dans le localStorage ou que vous stockiez votre token XSRF dans un cookie non HttpOnly, les deux peuvent être facilement saisis par XSS. Même votre JWT dans un cookie HttpOnly peut être saisi par une attaque XSS avancée comme XST method .

ainsi, en plus de la méthode Double soumettre des Cookies, vous devez toujours suivre les meilleures pratiques contre XSS y compris échapper au contenu. Cela signifie supprimer tout code exécutable qui pourrait amener le navigateur à faire quelque chose que vous ne voulez pas qu'il fasse. En général, cela signifie supprimer les balises // <![CDATA[ et les attributs HTML qui font que JavaScript est évalué.

pour en savoir plus:

82
répondu Iman Sedighi 2017-09-09 21:15:51