JWT doit-il être stocké dans localStorage ou cookie? [dupliquer]

Dans le but de sécuriser l'API REST à l'aide de JWT, selon certains documents (comme ce guide et cette question ), le JWT peut être stocké dans localStorage ou Cookies . Basé sur ma compréhension:

• localStorage est soumis à XSS et il n'est généralement pas recommandé d'y stocker des informations sensibles.
• Avec les 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 le backend, nous sommes alors soumis au CSRF.

Donc, sur la base du principe ci-dessus, il sera préférable de stocker JWT dans les cookies. À chaque demande adressée au serveur, le JWT sera lu à partir des cookies et ajouté dans l'en-tête d'autorisation en utilisant le schéma de support. Le serveur peut alors vérifier le JWT dans l'en-tête de la requête (au lieu de le lire à partir des cookies).

Ma compréhension est-elle correcte? Dans l'affirmative, l'approche ci-dessus présente-t-elle des problèmes de sécurité? Ou en fait, pouvons-nous simplement nous en sortir en utilisant localStorage en premier lieu?

J'aime la méthode XSRF Double Submit Cookies mentionnée 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 car l'attaquant peut injecter un script qui lit votre cookie CSRF (qui n'est pas HttpOnly), puis faire une demande à l'un de vos points de terminaison d'API à l'aide de ce jeton CSRF avec le cookie JWT envoyé automatiquement.

Donc, en réalité, vous êtes toujours vulnérable au XSS, c'est juste que l'attaquant ne peut pas voler votre jeton JWT pour une utilisation ultérieure, mais il peut toujours faire des demandes au nom de vos utilisateurs en utilisant XSS.

Que vous stockiez votre JWT dans un stockage local ou que vous stockiez votre jeton XSRF dans un cookie non http uniquement, les deux peuvent être facilement récupérés par XSS. Même votre cookie JWT dans HttpOnly peut être capturé par une attaque XSS avancée.

Ainsi, en plus de la méthode Double Submit Cookies, vous devez toujours suivre les meilleures pratiques contre XSS, y compris les contenus qui s'échappent. Cela signifie supprimer tout code exécutable qui amènerait le navigateur à faire quelque chose que vous ne voulez pas qu'il fasse. En règle générale, cela signifie supprimer les balises // <! [CDATA [et les attributs HTML qui entraînent l'évaluation de JavaScript.

Un message opportun de Stormpath a à peu près élaboré mes points et répondu à ma question.

TL; DR

Stockez le JWT dans les cookies, puis passez le JWT dans l'en-tête Authorization sur chaque demande comme je l'ai mentionné, ou comme le suggère l'article, comptez sur le backend pour empêcher CSRF (par exemple, xsrfTokenen cas d'utilisation angulaire).

• Ne stockez pas votre jeton dans LocalStorage ou SessionStorage, car un tel jeton peut être lu à partir de javascript et est donc vulnérable aux attaques XSS.
• Ne stockez pas votre jeton dans Cookie. Le cookie (avec le drapeau HttpOnly) est une meilleure option - il est sujet au XSS, mais il est vulnérable aux attaques CSRF

Au lieu de cela, lors de la connexion, vous pouvez fournir deux jetons: le jeton d'accès et le jeton d'actualisation. Le jeton d'accès doit être stocké dans la mémoire Javascript et le jeton d'actualisation doit être stocké dans HttpOnly Cookie. Le jeton d'actualisation est utilisé uniquement et uniquement pour créer de nouveaux jetons d'accès - rien de plus.

Lorsque l'utilisateur ouvre un nouvel onglet ou lors de l'actualisation du site, vous devez effectuer une demande de création d'un nouveau jeton d'accès, en fonction du jeton d'actualisation stocké dans le cookie.

Je recommande également vivement de lire cet article: https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/

Pour éviter les attaques CSRF qui tirent parti des cookies existants, vous pouvez définir votre cookie avec la SameSitedirective. Réglez-le sur laxou strict.

Il s'agit toujours d' un brouillon et à partir de 2019, il n'est pas entièrement pris en charge par tous les navigateurs actuels , mais en fonction de la sensibilité de vos données et / ou de votre contrôle sur les navigateurs que vos utilisateurs utilisent, cela peut être une option viable. La définition de la directive avec SameSite=laxautorisera "les navigations de haut niveau qui utilisent une méthode HTTP" sûre "."