Est-ce que JWT devrait être stocké dans un stockage local ou dans un cookie?
dans le but de sécuriser L'API REST en utilisant JWT, selon certains matériaux (comme ce guide et cette question ), le JWT peut être stocké dans localStorage ou Cookies . D'après ce que j'ai compris:
- localStorage est soumis à XSS et en général il n'est pas recommandé de stocker des informations sensibles en elle.
- avec Cookies nous pouvons appliquer le drapeau "httpOnly" qui atténue le risque de XSS. Cependant, si nous devons lire le JWT à partir des Cookies sur backend, nous sommes soumis à CSRF.
ainsi basé sur le principe ci - dessus-il sera préférable si nous stockons JWT dans les Cookies. Sur chaque requête au serveur, le JWT sera lu à partir des Cookies et ajouté dans l'en-tête D'autorisation en utilisant le schéma de titulaire. Le serveur peut alors vérifier le JWT dans l'en-tête de requête (par opposition à la lecture de cookies).
est-ce que ma compréhension est correcte? Dans l'affirmative, cette approche pose-t-elle des problèmes de sécurité? Ou en fait on peut juste s'en tirer avec localStorage en premier lieu?
2 réponses
j'aime la méthode XSRF Double Submit Cookies qui a mentionné dans l'article que @pkid169 a dit, mais il y a une chose que l'article ne vous dit pas. Vous n'êtes toujours pas protégé contre XSS parce que ce que l'attaquant peut faire est injecter un script qui lit votre cookie CSRF (qui n'est pas HttpOnly) et ensuite faire une demande à l'un de vos endpoints API en utilisant ce jeton CSRF avec le cookie JWT envoyé automatiquement.
donc en réalité vous êtes encore sensible à XSS, il est juste que l'attaquant ne peut pas vous voler JWT token pour une utilisation ultérieure, mais il peut toujours faire des requêtes au nom de vos utilisateurs en utilisant XSS.
que vous stockiez votre JWT dans un stockage local ou que vous stockiez votre token XSRF dans un cookie non seulement http, les deux peuvent être saisis facilement par XSS. Même votre cookie JWT dans HttpOnly peut être saisi par une attaque XSS avancée.
ainsi, en plus de la méthode Double soumettre des Cookies, vous devez toujours suivre le meilleur pratiques contre XSS, y compris l'évasion de contenus. 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 //
temps poste de Stormpath a assez bien élaboré de mes points et d'avoir répondu à ma question.
TL; DR
stocke le JWT dans les cookies, puis soit passer le JWT dans l'en-tête D'autorisation sur chaque requête comme je l'ai mentionné, ou comme l'article le suggère, compter sur le backend pour empêcher CSRF (par exemple en utilisant xsrfToken en cas D'angle).