Stockage local ou cookies? Stockage sécurisé des JWT sur le client

JWT (JSON Web Token) est un merveilleux standard basé sur JSON pour créer des jetons d'accès couramment utilisés pour l'authentification dans les applications client-serveur. Lors de l'utilisation de ces jetons, la question se pose de savoir comment les stocker en toute sécurité dans le front-end de l'application. Ce problème doit être résolu immédiatement après la génération du jeton sur le serveur et le transfert du côté client de l'application. Le matériel, dont nous publions aujourd'hui la traduction, est consacré à l'analyse des avantages et des inconvénients de l'utilisation du stockage local du navigateur ( ) et des cookies pour stocker les JWT.







localStorage

Types de jetons

• Les jetons d'accès sont généralement des JWT de courte durée signés par le serveur. Ils sont inclus dans chaque requête HTTP qu'un client fait à un serveur. Les jetons sont utilisés pour autoriser les demandes.
• Les jetons d'actualisation sont généralement des jetons de longue durée stockés dans une base de données et utilisés pour obtenir un nouveau jeton d'accès lorsque le jeton précédent expire.

Où exactement les jetons doivent-ils être stockés sur le client?

Il existe 2 façons courantes de stocker des jetons sur le client: le stockage du navigateur local et les cookies. Il y a beaucoup de débats sur la meilleure méthode. La plupart des gens se tournent vers les cookies en raison de leur meilleure sécurité.



Comparons le stockage local et les cookies. Notre comparaison est basée principalement sur ce matériel et sur les commentaires qui y sont associés.

Stockage local

▍Avantages

Le principal avantage du stockage local est qu'il est pratique à utiliser.

• Travailler avec le stockage local est très pratique, du JavaScript pur est utilisé ici. Si votre application n'a pas de backend et que vous comptez sur des API tierces, vous ne pourrez peut-être pas toujours demander à ces API de définir des cookies spécifiques pour votre site.
• En utilisant le stockage local, il est pratique de travailler avec des API qui nécessitent de placer un jeton d'accès dans l'en-tête de la demande. Par exemple - comme suit: Authorization Bearer ${access_token}.

▍ Inconvénients

Le principal inconvénient du stockage local est sa vulnérabilité aux attaques XSS.

• Lors d'une attaque XSS, un attaquant peut exécuter son code JavaScript sur votre site. Cela signifie qu'un attaquant peut accéder au jeton d'accès stocké dans localStorage.
• La source de l'attaque XSS peut être un code JavaScript tiers inclus dans votre site. Cela peut être quelque chose comme React, Vue, jQuery, script Google Analytics, etc. Dans les conditions modernes, il est presque impossible de développer un site qui n'inclut pas de bibliothèques tierces.

Biscuits

▍Avantages

Le principal avantage des cookies est qu'ils ne sont pas accessibles depuis JavaScript. En conséquence, ils ne sont pas aussi vulnérables aux attaques XSS que le stockage local.

• Si vous utilisez un indicateur HttpOnlyet des cookies sécurisés, cela signifie que JavaScript ne peut pas accéder à ces fichiers. Autrement dit, même si un attaquant peut exécuter son code sur votre page, il ne pourra pas lire le jeton d'accès à partir du cookie.
• Les cookies sont automatiquement envoyés dans chaque requête HTTP au serveur.

▍ Inconvénients

Selon les circonstances spécifiques, il peut arriver que les jetons contenus dans les cookies ne puissent pas être stockés.

• La taille des cookies est limitée à 4 Ko. Par conséquent, si vous utilisez des JWT volumineux, les stocker dans des cookies ne fonctionnera pas pour vous.
• Il existe des scénarios dans lesquels vous ne pouvez pas transmettre de cookies à votre serveur API. Il est également possible que certaines API nécessitent de placer un jeton dans l'en-tête Authorization. Dans ce cas, vous ne pourrez pas stocker de jetons dans les cookies.

Attaques XSS

Le stockage local est vulnérable aux attaques XSS car il est très facile de travailler avec JavaScript. Par conséquent, un attaquant peut accéder au jeton et l'utiliser à son avantage. Cependant, bien que les cookies HttpOnly ne soient pas accessibles à partir de JavaScript, cela ne signifie pas que vous êtes protégé contre les attaques XSS en utilisant des cookies pour voler un jeton d'accès.



Si un attaquant peut exécuter son code JS dans votre application, cela signifie qu'il peut simplement envoyer une requête à votre serveur, et le jeton sera automatiquement inclus dans cette requête. Un tel schéma de travail n'est tout simplement pas si pratique pour l'attaquant, car il ne peut pas lire le contenu du jeton. Mais les attaquants en ont rarement besoin. De plus, avec ce schéma de travail, il peut être plus rentable pour un attaquant d'attaquer le serveur en utilisant l'ordinateur de la victime, plutôt que le sien.

Cookies et attaques CSRF

Les attaques CSRF sont des attaques dans lesquelles un utilisateur est contraint d'une manière ou d'une autre à faire une demande spéciale. Par exemple, le site accepte les demandes de changement d'adresse e-mail:

POST /email/change HTTP/1.1
Host: site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
Cookie: session=abcdefghijklmnopqrstu

email=myemail.example.com

Dans une telle situation, un attaquant peut créer un formulaire avec un champ caché pour saisir une adresse e-mail à laquelle envoyer une requête POST https://site.com/email/change. Dans ce cas, les cookies de session seront automatiquement inclus dans une telle demande.



Cependant, cette menace peut être facilement protégée en utilisant l'attribut SameSitedans l'en-tête de réponse et les jetons anti-CSRF .

Sous-totaux

Bien que les cookies ne soient pas complètement à l'abri des attaques, la meilleure façon de stocker des jetons est, dans la mesure du possible, de les choisir localStorage. Pourquoi?

• Le stockage local et les cookies sont tous deux vulnérables aux attaques XSS, mais il sera plus difficile pour un attaquant d'attaquer si les cookies HttpOnly sont utilisés.
• Les cookies sont vulnérables aux attaques CSRF, mais le risque de telles attaques peut être atténué en utilisant l'attribut SameSiteet les jetons anti-CSRF .

Les cookies peuvent être utilisés même lorsque vous devez utiliser un en-tête Authorization: Bearerou lorsque le JWT est supérieur à 4 Ko. Ceci est également conforme aux directives OWASP: «Ne stockez pas les ID de session dans le stockage local, car les données correspondantes sont toujours disponibles à partir de JavaScript. Les cookies peuvent aider à atténuer vos risques avec HttpOnly. "

Utilisation de cookies pour stocker des jetons OAuth 2.0

Énumérons brièvement les façons de stocker les jetons:

• Méthode 1: stocker les jetons dans le stockage local. Cette méthode est sensible aux attaques XSS.
• Méthode 2: stockage des jetons dans les cookies HttpOnly. Cette méthode est sensible aux attaques CSRF, mais le risque de telles attaques peut être atténué. Cette option de stockage de jetons est légèrement mieux protégée contre les attaques XSS que la première.
• Méthode 3: stockez les jetons d'actualisation dans les cookies HttpOnly et accédez aux jetons en mémoire. Cette façon de stocker les jetons est plus sûre en termes d'attaques CSRF et légèrement mieux protégée contre les attaques XSS.

Ci-dessous, nous examinerons de plus près la troisième méthode de stockage des jetons, car elle, des trois répertoriées, semble la plus intéressante.

Pourquoi le stockage du jeton d'actualisation dans un cookie HttpOnly est-il plus sûr en termes d'attaques CSRF?

Un attaquant pourrait créer un formulaire qui accède /refresh_token. Un nouveau jeton d'accès est renvoyé en réponse à cette demande. Mais l'attaquant ne peut pas lire la réponse s'il utilise un formulaire HTML. Afin d'empêcher un attaquant d'exécuter avec succès des requêtes de récupération ou AJAX et de lecture des réponses, la politique CORS du serveur d'autorisation doit être configurée correctement, à savoir, afin que le serveur ne réponde pas aux requêtes provenant de sites Web non autorisés.



Comment le configurez-vous?

Étape 1: renvoyer le jeton d'accès et le jeton d'actualisation lors de l'authentification de l'utilisateur

Une fois que l'utilisateur s'est authentifié, le serveur d'authentification renvoie access_token(jeton d'accès) et refresh_token(jeton d'actualisation). Le jeton d'accès sera inclus dans le corps de la réponse et le jeton d'actualisation dans le cookie.



Voici ce que vous devez utiliser pour configurer des cookies pour stocker des jetons d'actualisation:

• Flag HttpOnly- pour empêcher JavaScript de lire le jeton.
• Un indicateur secure=truequi entraînera la transmission des données uniquement via HTTPS.
• Le drapeau SameSite=strictdoit être utilisé chaque fois que possible pour se protéger contre les attaques CSRF. Cette approche ne peut être utilisée que si le serveur d'autorisation appartient au même site que l'interface du système. Si ce n'est pas le cas, le serveur d'autorisation doit définir les en-têtes CORS sur le backend ou utiliser d'autres méthodes pour garantir que la demande avec le jeton d'actualisation ne peut être effectuée que par un site Web autorisé.

Étape 2: stocker le jeton d'accès en mémoire

Le stockage du jeton d'accès en mémoire signifie que le jeton, dans le code du frontend, est écrit dans une variable. Cela signifie bien sûr que le jeton sera perdu si l'utilisateur ferme l'onglet où le site est ouvert ou actualise la page. C'est pourquoi nous avons un jeton d'actualisation.

Étape 3: obtenir un nouveau jeton d'accès à l'aide du jeton d'actualisation

Si le jeton d'accès est perdu ou non valide, vous devez contacter le point de terminaison /refresh_token. Dans ce cas, le jeton d'actualisation, qui, à l'étape 1, a été enregistré dans le cookie, sera inclus dans la demande. Vous recevrez ensuite un nouveau jeton d'accès que vous pourrez utiliser pour effectuer des requêtes API.



Tout cela signifie que les JWT peuvent être plus grands que 4 Ko, et qu'ils peuvent être placés dans l'en-tête Authorization.

Résultat

Ce que nous avons couvert ici devrait vous donner quelques informations de base sur le stockage des JWT sur le client et comment rendre votre projet plus sécurisé.



Comment stockez-vous JWT sur le client?