Meilleur endroit pour stocker les jetons d'authentification côté client
Lorsque mes utilisateurs sont authentifiés, ils reçoivent un jeton d'authentification, je dois utiliser ce jeton d'authentification pour autoriser certains appels asp.net WebAPI. Pour ce faire, je dois ajouter le jeton à la tête de cet appel, j'ai donc besoin du jeton accessible depuis le navigateur des utilisateurs. Je pense que le stockage du jeton dans un cookie n'est pas le moyen le plus sûr, alors quel est le moyen le plus sûr de stocker ce jeton et toujours accessible dans mon javascript pour effectuer des appels API?
Il existe deux façons d'enregistrer les informations d'authentification dans le navigateur:
- Biscuits
- Stockage Web HTML5
Dans chaque cas, vous devez vous assurer que les navigateurs sont correctement mis en œuvre et que le site Web A ne peut pas accéder en quelque sorte aux informations d'authentification du site Web B. Dans ce sens, les deux mécanismes de stockage sont également sécurisés. Des problèmes peuvent survenir quant à la façon dont vous les utilisez.
Si vous utilisez des cookies:
- Le navigateur enverra automatiquement les informations d'authentification à chaque demande à l'API. Cela peut être pratique tant que vous savez que cela se produit.
- Vous devez vous rappeler que le CSRF est une chose, et y faire face.
Si vous utilisez le stockage Web HTML5:
- Vous devez écrire Javascript qui gère exactement quand et quelles informations d'authentification sont envoyées.
La grande différence que les gens se soucient est qu'avec les cookies, vous devez vous soucier de CSRF. Pour gérer correctement CSRF, vous avez généralement besoin d'un supplémentaire "jeton de synchronisation".
Les frameworks Web tout-en-un (comme Grails, Rails, probablement asp.net) fournissent généralement un moyen facile d'activer la protection CSRF et d'ajouter automatiquement des éléments de jeton de synchroniseur dans votre interface utilisateur. Mais si vous écrivez une interface utilisateur à l'aide d'un cadre Web côté client uniquement (comme AngularJS ou BackboneJS), vous devrez écrire du Javascript pour gérer le jeton de synchronisation. Donc, dans ce cas, vous pouvez tout aussi bien adopter l'approche de stockage Web HTML5 et ne vous soucier que d'un seul jeton.
Quelques autres différences sont discutées ici .
modifier une recherche Google révèle this pour asp.net - ils appellent le jeton de synchronisation un "jeton de vérification de demande".
La meilleure façon de protéger votre jeton d'accès est de ne pas le stocker du tout côté client.
Comment ça marche? Eh bien, au moment de générer le jeton d'accès, générez un autre cryptographiquement sécurisé PRNG (que vous mappez au jeton d'accès sur le serveur), mappez ceci au ID de session des utilisateurs et renvoyez-le au client à la place.
Cela réduira la zone d'attaque car ce que vous retournez maintenant est un jeton lié à une session, et les deux seraient nécessaires pour autoriser le jeton. Lorsque la session expire, le jeton fait de même, naturellement, et l'utilisateur serait obligé de se réauthentifier, générant ainsi un nouveau jeton d'accès.
Ce n'est toujours pas sûr à 100%, cependant, vous devez évaluer la possibilité que quelque chose comme ça se produise dans une session d'utilisateurs. Sur cette base, vous pouvez ensuite modifier les heures d'expiration de votre session/jeton en fonction de vos besoins, bien que vous deviez également vous méfier de la convivialité - vous ne voulez pas expirer des sessions après 5 minutes, car devoir vous reconnecter en permanence peut être fastidieux ( ou peut-être que vous le pouvez, dépend du type d'application).
ARMOR est spécialement conçu pour répondre à cette exigence. Le jeton Anti-falsification peut être stocké n'importe où sur l'interface utilisateur que vous jugez bon. La bibliothèque est équipée d'un composant JavaScript personnalisé qui extrait le jeton de l'interface utilisateur et l'inclut automatiquement dans les en-têtes AJAX.
Voici un tutoriel sur le sujet, et voici le repo GitHub .
Vous devez envoyer le jeton au serveur à chaque requset. Peu importe que vous le stockiez dans un stockage de cookies ou html 5. Les deux sont des stockages sécurisés et tous ceux qui ont accès à la machine client ont également accès au jeton.
Mais je recommande de ne pas utiliser le jeton soumis dans le cookie sur votre serveur pour empêcher l'attaque CSRF. Je pense que c'est une bonne idée d'inclure manuellement le jeton dans chaque demande que vous faites chaque fois que nécessaire.
L'utilisation de cookies augmente également l'en-tête de la demande, ce qui n'est pas approprié.
Je stocke le jeton dans un cookie avec les trois indicateurs suivants: 1. Sécurisé: transmettez via https 2. HttpOnly: le JS côté client ne peut pas le lire (protection XSS) 3. SameSite (Lax ou Strict): Protection CSRF
De cette façon, vous êtes immunisé contre XSS et CSRF. Il suffit de faire attention à SameSite, car il est relativement nouveau et n'a été pris en charge que récemment par les 4 principaux navigateurs (Chrome, FF, Safari, Edge) voir: https://caniuse.com/#feat= attribut de cookie du même site
Pour plus d'informations sur le durcissement des cookies, voir https://odino.org/security-hardening-http-cookies/
Le blog d'Alex doit être informatif.
Un serveur meurt chaque fois que quelqu'un implémente OAuth sur une seule page est une application web. Arrêtez le génocide! Utilisez un proxy côté serveur! Agissez maintenant!