Get best of the week

À propos du stockage des jetons JWT dans les navigateurs


Le standard ouvert JWT est officiellement apparu en 2015 ( rfc7519 ) promettant des fonctionnalités intéressantes et de larges perspectives. Le stockage approprié du jeton Access est vital pour la construction d'un système d'autorisation et d'authentification sur le Web moderne, où les sites construits à l'aide de la technologie SPA deviennent de plus en plus populaires.

Un stockage incorrect des jetons entraîne leur vol et leur réutilisation par les attaquants.

Alors, où stocker?


Considérez les principales options de stockage du jeton d'accès JWT dans un navigateur:

  1. Stockage local / stockage de session - la méthode n'est pas sûre et est susceptible aux attaques comme XSS, en particulier si vous connectez des scripts à partir de CDN tiers (l'ajout de l'attribut d'intégrité ne peut pas garantir une sécurité à 100%), ou si vous n'êtes pas sûr que les scripts que vous connectez n'ont pas la capacité de «fusionner» les données de rangements sur le côté. De plus, si le stockage local est disponible entre les onglets, le stockage de session n'est disponible que dans un seul onglet et l'ouverture d'un site dans un nouvel onglet ne provoquera qu'un nouveau cycle de jeton d'accès / autorisation.
  2. , , fetch . – .
  3. Cookies. «» cookie sessions. Access cookie CSRF. XSS . CSRF Cookie SameSite Strict– , , credentials, CSRF .
    – Access JS httpOnly, Secure .

    Un point important est de définir un cookie uniquement pour l'api de domaine / chemin afin que les demandes aux statistiques publiques ne contiennent pas de surcharge dans l'en-tête.

Quel est le résultat?


Les cookies, lorsqu'ils sont utilisés correctement, sont la solution appropriée et la plus sûre pour stocker le jeton d'accès JWT pour le moment et doivent suivre les règles suivantes:

  1. Être installé pour l'API domaine / chemin pour éviter les frais généraux lors de la demande de fichiers statiques (images publiques / styles / fichiers js).
  2. Avoir un drapeau sécurisé (pour le transfert uniquement via https).
  3. Avoir le drapeau httpOnly (pour l'impossibilité d'accéder à partir de JavaScript).
  4. L'attribut SameSite doit être Strict pour protéger contre les attaques CSRF, interdire le transfert de cookies si la transition vers votre API ne provient pas du domaine défini dans le cookie.

Côté serveur, il doit également être configuré:

  1. Content-Security-Policy - restreindre les domaines approuvés pour empêcher d'éventuelles attaques XSS
  2. En- tête X-Frame-Options pour se protéger contre les attaques de détournement de clics.
  3. X-XSS-Protection - force le mécanisme de protection intégré du navigateur contre les attaques XSS.
  4. X-Content-Type-Options - pour se protéger contre la substitution des types MIME.

Le respect de ces mesures, couplé à une rotation fréquente des jetons Accès / Rafraîchissement, devrait permettre d'assurer un haut niveau de sécurité sur le site.

Limites


Malgré le fait que l'attribut SameSite est pris en charge dans de nombreux navigateurs populaires , il existe également des navigateurs qui ne le prennent pas en charge ou le prennent en charge partiellement (bonjour IE et Safari pour Mac). Pour ces cas, vous avez besoin d'un retour aux jetons CSRF. Dans ce cas, avec les demandes à l'API, le jeton CSRF doit également être transmis. Le jeton CSRF correct doit être généré par le serveur en tenant compte de l' empreinte digitale de l' utilisateur afin de minimiser la probabilité de sa substitution.

More articles:


All Articles