Est-il sûr de stocker un jwt dans localStorage avec reactjs?
Je construis actuellement une application d'une seule page en utilisant reactjs. J'ai lu que la plupart des raisons de ne pas utiliser localStorage sont dues à des vulnérabilités XSS. Puisque React échappe à toutes les entrées de l'utilisateur, serait-il maintenant sûr d'utiliser localStorage?
5 réponses
Dans la plupart des applications modernes à une seule page, nous devons en effet stocker le jeton quelque part du côté client (cas d'utilisation le plus courant - pour garder l'utilisateur connecté après une actualisation de la page).
Il y a un total de 2 options disponibles: stockage Web (stockage de session, stockage local) et un cookie côté client. Les Deux options sont largement utilisées, mais cela ne signifie pas qu'elles sont très sécurisées.
Tom Abbott résume bien le JWT sessionStorage et localStorage de sécurité:
Le Stockage Web (localStorage/sessionStorage) est accessible via JavaScript sur le même domaine. Cela signifie que tout JavaScript exécuté sur votre site aura accès au stockage web, et à cause de cela peut être vulnérable aux attaques XSS (cross-site scripting) . XSS, en un mot, est un type de vulnérabilité où un attaquant peut injecter JavaScript qui s'exécutera sur votre page. Les attaques XSS de base tentent d'injecter JavaScript via des entrées de formulaire, où le l'attaquant met
<script>alert('You are Hacked');</script>dans un formulaire pour voir s'il est exécuté par le navigateur et peut être consulté par d'autres utilisateurs.
Pour empêcher XSS, la réponse commune est d'échapper et d'encoder toutes les données non approuvées. Réagir (surtout) le fait pour vous! Voici une excellente discussion sur la protection contre les vulnérabilités XSS dont React est responsable .
Mais cela ne couvre pas toutes les vulnérabilités possibles! Une autre menace potentielle est L'utilisation de JavaScript hébergé sur CDNs ou à l'extérieur infrastructure .
Voici encore Tom:
Les applications Web modernes incluent des bibliothèques JavaScript tierces pour les tests A / B, l'analyse entonnoir/marché et les publicités. Nous utilisons des gestionnaires de paquets comme Bower pour importer le code d'autres personnes dans nos applications.
Que faire si un seul des scripts que vous utilisez est compromis? JavaScript malveillant peut être intégré sur la page, et le stockage Web est compromise. Ces types D'attaques XSS peuvent obtenir le stockage Web de tout le monde qui visite votre site, à leur insu. C'est probablement pourquoi un tas d'organisations conseillent de ne pas stocker quoi que ce soit de valeur ou de faire confiance à toute information dans le stockage web. Cela inclut les identifiants de session et les jetons.
Par conséquent, ma conclusion est qu'en tant que mécanisme de stockage, le stockage Web n'applique aucune norme sécurisée pendant le transfert . Quiconque lit le stockage Web et l'utilise doit faire preuve de diligence raisonnable pour s'assurer qu'il envoie toujours le JWT via HTTPS et jamais HTTP.
Je sais que c'est une vieille question mais selon ce que dit @mikejones1477, les bibliothèques et les frameworks frontaux modernes échappent au texte en vous protégeant contre XSS. La raison pour laquelle les cookies ne sont pas une méthode sécurisée utilisant des informations d'identification est que les cookies n'empêchent pas CSRF lorsque localStorage le fait, cette réponse reprend pourquoi.
La raison pour laquelle stocker un jeton d'authentification dans le stockage local et l'ajouter manuellement à chaque requête protège contre CSRF est ce mot clé: manuel. Puisque le navigateur n'envoie pas automatiquement ce jeton d'authentification, si je visite evil.com et il parvient à envoyer un message http://example.com/delete-my-account , il ne pourra pas envoyer mon jeton authn, donc la requête est ignorée.
Bien sûr, httpOnly est le Saint Graal, mais vous ne pouvez pas accéder à partir de reactjs ou de tout framework js à côté de vous avez toujours une vulnérabilité CSRF. Ma recommandation serait localstorage ou si vous souhaitez utiliser des cookies assurez vous d'implémenter une solution à votre problème CSRF comme django fait .
En ce qui concerne les CDN, assurez-vous que vous n'utilisez pas de CDN bizarre, par exemple CDN comme google ou bootstrap, sont maintenus par la communauté et ne contiennent pas de code malveillant, si vous n'êtes pas sûr, vous êtes libre d'examiner.
Ce N'est pas sûr si vous utilisez des CDN:
JavaScript malveillant peut être intégré sur la page, et le stockage Web est compromis. Ces types D'attaques XSS peuvent obtenir le stockage Web de tout le monde qui visite votre site, à leur insu. C'est probablement pourquoi un tas d'organisations conseillent de ne pas stocker quoi que ce soit de valeur ou de faire confiance à toute information dans le stockage web. Cela inclut les identifiants de session et les jetons.
Par stormpath
Tout script que vous exiger de l'extérieur pourrait potentiellement être compromise et pourrait saisir n'importe quel JWT du stockage de votre client et envoyer des données personnelles au serveur de l'attaquant.
Fondamentalement, il est correct de stocker votre JWT dans votre localStorage.
Et je pense que c'est une bonne façon. Si nous parlons de XSS, XSS utilisant CDN, c'est aussi un risque potentiel d'obtenir votre connexion/passe client. Le stockage des données dans le stockage local empêchera au moins les attaques CSRF.
Vous devez être conscient des deux et choisir que vous voulez. Les deux attaques ne sont pas tout ce que vous devez savoir, rappelez-vous simplement: vous êtes sécurisé comme POINT moins sécurisé de votre application.
Encore une fois stocker est OK, être vulnérable à XSS, CSRF,... n'est pas
Localstorage est conçu pour être accessible par javascript, il ne fournit donc aucune protection XSS. Comme mentionné dans d'autres réponses, il existe un tas de façons possibles de faire une attaque XSS, à partir de laquelle localstorage n'est pas protégé par défaut.
Cependant, les cookies ont des indicateurs de sécurité qui protègent contre les attaques XSS et CSRF. L'indicateur HttpOnly empêche le javascript côté client d'accéder au cookie, L'indicateur Secure permet uniquement au navigateur de transférer le cookie via ssl et L'indicateur SameSite s'assure que le cookie est envoyé uniquement à l'origine. Bien que je viens de vérifier et SameSite est actuellement pris en charge uniquement dans Opera et Chrome, donc pour protéger de CSRF, il est préférable d'utiliser d'autres stratégies. Par exemple, l'envoi d'un jeton crypté dans un autre cookie avec des données d'utilisateur publiques.
Les cookies sont donc un choix plus sécurisé pour stocker les données d'authentification.