La recommandation de l'OWASP concernant le stockage local est-elle toujours valable?
Je travaille actuellement sur une application qui est une application d'une seule page construite avec Angular. Il est servi sur HTTPS, en utilisant HSTS.
Pour l'authentification, nous utilisons Auth0. La documentation Auth recommande de stocker le jeton d'accès dans localstorage.
Un intercepteur est ensuite utilisé pour l'ajouter à l'en-tête de chaque requête HTTP.
Cependant, cette réponse recommande de ne stocker aucune information sensible avec localstorage.
La réponse est de 2011, et l'auteur a également co-écrit la feuille de triche OWASP HTML5, qui déclare:
Faites particulièrement attention aux appels "localStorage.getItem" et "setItem" implémentés dans la page HTML5. Il aide à détecter quand les développeurs créent des solutions qui mettent des informations sensibles dans le stockage local, ce qui est une mauvaise pratique.
Je me demande si la situation en 2017/2018 a changé. Suis-je d'accord pour suivre les directives d'Auth0, ou devrais-je adopter une autre approche?
Personnellement, je ne vois aucun problème avec l'utilisation du stockage local tant que vous n'êtes pas satisfait que l'utilisateur n'ait pas à se réauthentifier entre les sessions. La réponse liée fournit l'argument suivant contre cela. Je dirais que c'est très faible -
Le mécanisme de stockage sous-jacent peut varier d'un agent utilisateur à l'autre. En d'autres termes, toute authentification requise par votre application peut être contournée par un utilisateur disposant de privilèges locaux sur la machine sur laquelle les données sont stockées. Par conséquent, il est recommandé de ne stocker aucune information sensible dans le stockage local.
Cela s'applique à tout type de jeton d'authentification. Quelqu'un local avec des privilèges d'administrateur (en supposant qu'il ne soit pas chiffré avec une clé liée aux informations d'identification des utilisateurs) peut le lire depuis n'importe quel type de stockage, RAM ou peut-être même directement depuis le réseau.
Il suggère également -
(ou faille XSS dans le site Web)
Encore une fois - cela s'applique à tout type de jeton auquel JavaScript peut accéder.
La raison pour laquelle le stockage local est considéré comme dangereux est que tout JavaScript exécuté dans le contexte de la page peut y accéder. Cela vous ouvre au détournement de session via XSS réfléchissant et les vulnérabilités XSS stockées, potentiellement la divulgation d'informations en fonction du contenu de votre jeton.
Par exemple: si un utilisateur accède à une page avec du contenu partagé entre d'autres utilisateurs et qu'il existe une vulnérabilité XSS stockée, un autre utilisateur peut injecter une attaque qui volera votre jeton de localstorage.
Une expiration courte protège uniquement votre jeton contre les attaques de relecture, mais si une vulnérabilité XSS existe avec l'accès à localstorage, cela n'aura aucun effet sur les sessions actives, car vous pouvez écrire un mécanisme d'interrogation pour extraire à nouveau le jeton de localstorage à l'expiration.
Je vous suggère d'utiliser un cookie comme stockage pour votre jeton.
- Les cookies ne peuvent être marqués que HTTP. Cela empêchera JavaScript d'accéder au cookie
- Sur le serveur, demandez à votre code d'extraire le jeton du cookie, puis de le valider
- Marquez-le également comme sécurisé pour HTTPS uniquement
Désolé, pas assez de points pour répondre, alors laissez tomber ici:
Une autre considération, quel est votre modèle de menace? Attaquants externes sur le web: Stockez le jeton dans un processus de cookie sur le serveur Utilisateurs sur la même machine (Non administrateur): Peut-être le stockage de session donc pas de persistance Administrateur local: Eh bien rien - ils sont administrateur local, ils possèdent le système
La certification client n'est pas vraiment un élément d'authentification viable pour les applications Web en tant qu'utilisateur - les authentificateurs MFA sont la meilleure alternative
En suivant les conseils de le blog auth vous pouvez contrer les problèmes de sécurité en conservant une valeur d'expiration de jeton faible et, plus important encore, vous pouvez crypter le jeton.
Une autre approche serait l'utilisation de jetons Web JSON en association avec OAuth2.
Je ne suis pas à 100% en sécurité. J'en ai lu autre chose.
Le problème avec les "informations de jeton sensibles" est le même problème, que ce soit un cookie ou localStorage.
Mais vous pouvez enregistrer beaucoup plus de données dans le stockage local, ce qui pourrait donner lieu à l'idée que c'est une bonne idée de stocker toutes les informations bancaires, tous les virements, etc. (veuillez insérer d'autres informations à risque entendre. Médicales, judiciaires, ... ) dans le stockage local, vous pouvez donc y accéder hors ligne.
Le risque de sécurité d'un cookie ou d'une session est atténué par un délai d'expiration de session côté serveur. Mais le stockage local n'a pas de délai d'expiration. Donc, si vous stockez quelque chose dans le stockage local, préparez-vous à ce qu'il y reste pour toujours. Si vous ne voulez pas que tous ceux qui ont accès à la machine puissent la lire - assurez-vous de la supprimer et assurez-vous que votre mécanisme fonctionne dans "toutes les circonstances" (quoi que cela signifie dans le contexte de stockage local - à mon humble avis, ce n'est pas possible. Mais je suis un développeur php, veuillez me corriger.)