Je suis en train de construire une application à page unique en utilisant ReactJS.
J'ai lu que l'une des raisons pour lesquelles on n'utilise pas localStorage est dû à des vulnérabilités XSS.
Puisque React échappe toutes les entrées de l'utilisateur, serait-il maintenant sécuritaire d'utiliser localStorage ?
Dans la plupart des applications modernes à page unique, nous devons en effet stocker le jeton quelque part du côté client (cas d'utilisation le plus courant - pour que l'utilisateur reste connecté après un rafraîchissement de la page).
Il y a un total de 2 options disponibles : Web Storage (stockage de session, stockage local) et un cookie côté client. Ces deux options sont largement utilisées, mais cela ne signifie pas qu'elles sont très sûres.
Tom Abbott résume bien la Sécurité de JWT sessionStorage et localStorage :
Le stockage Web (localStorage/sessionStorage) est accessible par JavaScript sur le même domaine. Cela signifie que tout JavaScript s'exécutant sur votre site aura accès au stockage Web, et de ce fait, le stockage Web est accessible à tous. peut être vulnérable aux attaques de type "cross-site scripting" (XSS) . En résumé, XSS est un type de vulnérabilité dans lequel un attaquant peut injecter du JavaScript qui s'exécutera sur votre page. Les attaques XSS de base tentent d'injecter du JavaScript par le biais d'entrées de formulaire, où 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 éviter les XSS, la réponse commune est d'échapper et de coder toutes les données non fiables. React le fait (presque) pour vous ! Voici un excellent discussion sur le degré de 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 des CDN ou des infrastructures externes .
Voici encore Tom :
Les applications web modernes incluent des bibliothèques JavaScript tierces pour les tests A/B, l'analyse des entonnoirs et du marché, et les publicités. Nous utilisons des gestionnaires de paquets comme Bower pour importer le code d'autres personnes dans nos applications.
Et si un seul des scripts que vous utilisez est compromis ? Un JavaScript malveillant peut être intégré à la page, et le stockage Web est compromis. Ces types d'attaques XSS peuvent obtenir le stockage Web de toute personne qui visite votre site, à son insu. C'est probablement la raison pour laquelle un grand nombre d'organisations conseillent de ne pas stocker d'éléments de valeur ou de ne pas faire confiance à des informations dans le stockage Web. Cela inclut les identifiants de session et les jetons.
Par conséquent, ma conclusion est que, en tant que mécanisme de stockage, le stockage Web n'applique pas de normes de sécurité pendant le transfert . Quiconque lit Web Storage et l'utilise doit faire preuve de diligence raisonnable pour s'assurer qu'il envoie toujours le JWT par HTTPS et jamais par HTTP.
Oui. Je recommande les cookies en raison de la sécurité supplémentaire qu'ils apportent et de la simplicité de la protection contre les CSRF avec les frameworks web modernes. Le stockage Web (localStorage/sessionStorage) est vulnérable à XSS, présente une plus grande surface d'attaque et peut avoir un impact sur tous les utilisateurs de l'application en cas d'attaque réussie.
Je crois que vous les avez mélangés. Les frameworks web modernes ont de fortes défenses intégrées pour XSS. Mais pas autant pour le xsrf. La meilleure défense contre le xsrf est d'éviter complètement l'utilisation des cookies. Le stockage local est limité à un domaine spécifique, ce qui signifie que le domaine d'un attaquant ne peut pas y accéder. Les frameworks Web se défendent contre xss en codant et en aseptisant automatiquement les entrées de l'utilisateur. Voir angular.io/guide/security
En principe, il est possible de stocker votre JWT dans votre localStorage.
Et je pense que c'est un bon moyen. Si nous parlons de XSS, XSS utilisant un CDN, c'est aussi un risque potentiel d'obtenir le login/pass de votre 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 ce que vous voulez. Les deux attaques ne sont pas la seule chose dont vous devez être conscient, rappelez-vous simplement : VOTRE APP DANS SON ENSEMBLE N'EST PAS PLUS SÉCURISÉ QUE LE POINT LE MOINS SÉCURISÉ DE VOTRE APP.
Une fois de plus, stocker est acceptable, être vulnérable à XSS, CSRF,... ne l'est pas.
C'est pourquoi il est sûr de faire ce qui suit : - stocker le JWT dans un cookie afin qu'il ne puisse pas être récupéré par XSS - stocker un jeton CSRF dans localStorage afin qu'il ne puisse pas être récupéré par CSRF.
Vous soulevez un bon point : si votre site exécute un script malveillant, la partie est terminée de toute façon. Ils peuvent simplement lier les événements keydown aux entrées de type password et voler les informations d'authentification de votre utilisateur de cette façon (ce qui est bien, bien pire que de voler un jeton d'authentification JWT). Stocker les JWTs dans localStorage ne fait rien pour augmenter les dommages possibles déjà immenses de XSS.
Je sais que c'est une vieille question, mais d'après ce qu'a dit @mikejones1477, les bibliothèques et frameworks frontaux modernes échappent le texte, ce qui vous protège contre les XSS. La raison pour laquelle les cookies ne sont pas une méthode sûre pour utiliser les informations d'identification est que les cookies n'empêchent pas CSRF alors que localStorage le fait (rappelez-vous aussi que les cookies sont accessibles par javascript aussi, donc XSS n'est pas le gros problème ici), cette réponse résume pourquoi .
La raison pour laquelle l'enregistrement d'un jeton d'authentification dans le stockage local et son ajout manuel à 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 qu'il parvient à envoyer un POST http://example.com/delete-my-account il ne sera pas en mesure d'envoyer mon jeton d'authentification, donc la demande est ignorée.
Bien sûr, httpOnly est le Saint Graal, mais vous ne pouvez pas y accéder à partir de reactjs ou de tout autre framework js, sans compter que vous avez toujours une vulnérabilité CSRF. Ma recommandation serait le stockage local ou si vous voulez utiliser des cookies, assurez-vous d'implémenter une solution à vos problèmes de sécurité. Problème de CSRF comme pour django .
En ce qui concerne les CDN, assurez-vous que vous n'utilisez pas des CDN bizarres, par exemple des CDN comme ceux fournis par google ou bootstrap, qui sont maintenus par la communauté et ne contiennent pas de code malveillant. Si vous n'êtes pas sûr, vous pouvez les vérifier.
Je ne sais pas pourquoi vous dites que vous êtes toujours vulnérable à CSRF en utilisant des cookies. L'utilisation d'un cookie avec les drapeaux HttpOnly SameSite=strict y secure Les informations que vous avez définies dans les cookies seront protégées. Ensuite, contre les XSS, il suffit de s'assurer que votre JavaScript n'est pas au courant des données liées à l'authentification, comme les jetons et les mots de passe (ce qui signifie qu'il ne faut pas les stocker dans le Web Storage) - si vous importez un script malveillant, ce script n'aura pas accès aux données sensibles. Oui, vous n'aurez pas non plus accès au jeton via JS, mais cela ne devrait vraiment pas poser de problème.
@miphe c'est ce que j'ai dit. Mais l'OP demande un moyen d'accéder à partir de javascript. Ici, j'explique simplement quelle est la meilleure façon de stocker un jeton accessible depuis javascript.
Le stockage du jeton d'authentification dans un cookie est sécurisé tant que vous ne lisez pas ce cookie sur le serveur. Le client peut récupérer le jeton dans le cookie et l'envoyer dans un message de type Authorization en-tête. Le serveur ne doit utiliser que le jeton d'authentification de l'en-tête Authorization et ne pas tenir compte du cookie.
Ce n'est pas sûr si vous utilisez des CDN :
Un JavaScript malveillant peut être intégré à la page, et le stockage Web est compromis. Ces types d'attaques XSS peuvent obtenir le stockage Web de toute personne qui visite votre site, à son insu. C'est probablement la raison pour laquelle de nombreuses organisations conseillent de ne pas stocker d'éléments de valeur ou de ne pas faire confiance à des informations dans le stockage Web. Cela inclut les identifiants de session et les jetons.
Tout script que vous exigez de l'extérieur pourrait potentiellement être compromis et pourrait saisir n'importe quel JWTS du stockage de votre client et renvoyer des données personnelles au serveur de l'attaquant.
L'auteur de l'article n'a jamais fait de distinction entre les XSS sur les sites servis via un CDN ou directement depuis un serveur central. Votre explication ne s'appliquerait-elle pas de manière générale, et pas seulement pour les CDN ?
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 grand nombre de façons possibles de réaliser une attaque XSS, contre lesquelles Localstorage n'est pas protégé par défaut.
Toutefois, les cookies possèdent des indicateurs de sécurité qui les 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 ne permet au navigateur de transférer le cookie que par ssl, et l'indicateur SameSite garantit que le cookie est envoyé uniquement à l'origine. Je viens de vérifier que SameSite n'est actuellement pris en charge que par Opera et Chrome. Pour se protéger de CSRF, il est donc préférable d'utiliser d'autres stratégies. Par exemple, envoyer un jeton crypté dans un autre cookie contenant des données publiques de l'utilisateur.
Les cookies constituent donc un choix plus sûr pour le stockage des données d'authentification.
@AlexLyalka Je ne voulais pas dire que HttpOnly empêche le CSRF, mais plutôt que tous les drapeaux de cookies ensemble peuvent protéger contre XSS et CSRF. SameSite fournit une certaine protection, en empêchant les cookies d'être envoyés vers un site différent de l'origine. Cependant, je viens de vérifier et le support pour ce drapeau est très faible. Il est également possible d'éviter le CSRF avec un jeton crypté séparé avec une certaine identification de l'utilisateur, qui est vérifié sur le serveur.
Eh bien, si quelqu'un peut exécuter du code sur votre site, ne peut-il pas simplement poster un message sur votre site au nom de votre utilisateur ? Ok, il ne peut pas obtenir vos cookies http seulement, mais il peut faire des appels en utilisant ces cookies, donc je ne vois toujours pas l'intérêt
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
7 votes
Préférer le stockage des sessions
19 votes
"Ne pas stocker les jetons dans le stockage local" - Auth0
5 votes
"Il est recommandé de ne pas stocker d'informations sensibles dans le stockage local." -OWASP "les stocker en mémoire sans aucune persistance" -Auth0
7 votes
Je pense que Auth0 a peut-être changé de point de vue à ce sujet - parce que je ne trouve pas la citation ci-dessus dans le lien fourni
2 votes
Pour être juste, @DauleDK, je pense que cette citation particulière est manquante non pas parce que Auth0 pense maintenant qu'il est sûr de le faire, mais plutôt le contraire -- Si vous lisez cette page, il apparaît maintenant qu'ils conseillent que le jeton ne soit jamais persistant dans une solution uniquement côté client, quelle que soit la technique de persistance utilisée : "Si vous avez un SPA sans serveur backend correspondant, votre SPA devrait demander de nouveaux tokens lors de la connexion et les stocker en mémoire sans aucune persistance. Pour effectuer des appels d'API, votre SPA utiliserait alors la copie en mémoire du jeton."
1 votes
C'est un point juste @NotTheDr01ds - si le stockage de JWT's dans un SPA doit être pris en compte. Mais la vraie question semble être de savoir si des cookies auraient dû être utilisés, comme une meilleure alternative.