Comme nous le savons, les services Rest sont sans état, les stratégies générales d'authentification utilisent une authentification basée sur des jetons.
Dans le service de connexion, il faut des informations d'identification qui renvoient un jeton.
Ce jeton peut être défini dans les cookies du client, et toutes les demandes ultérieures utilisent ce jeton pour être validées et traiter une nouvelle demande si le jeton est valide.
Ma question est maintenant de savoir comment valider le jeton? Si quelqu'un a volé le jeton et tente d'accéder aux services de repos avec un jeton volé en modifiant simplement les cookies, comment peut-il être identifié et restreint?
Nous ne pouvons jamais savoir si le jeton est récupéré par un utilisateur valide et le même utilisateur essaie d'accéder à la demande suivante. mais quels sont les moyens possibles de rendre les choses plus difficiles, comme vérifier si la demande provient de la même source?
Une suggestion générale est de définir le vieillissement pour les jetons / cookies, mais cela n'est toujours pas utile jusqu'à l'âge de ces jetons / cookies.
Toutes les suggestions seraient appréciées.
5 Réponses :
Je ne pense pas qu'il existe des méthodes à 100% infaillibles pour empêcher l'accès avec des jetons d'utilisateurs volés. Comment savez-vous que le jeton est volé en premier lieu? Mais du haut de ma tête, vous voudrez peut-être envisager de suivre:
Au Royaume-Uni, les FAI bien connus changent fréquemment les adresses IP des utilisateurs - équilibre la sécurité avec l'expérience utilisateur
attribuer la prime car elle expirait, et cette réponse était plus pertinente, mais nous avons mis en œuvre une solution appropriée. J'ai expliqué la même chose dans ma réponse.
Ma compréhension actuelle de l'approche "la plus sécurisée" pour autoriser les requêtes dans le navigateur est d'exiger la validation d'un cookie HttpOnly SameSite ET d'un en-tête HTTP (par exemple, Authorization ou X-CSRF-Token ) en combinaison.
Par exemple, lors de l'émission du JWT vers un navigateur, envoyez la signature JWT dans un cookie HttpOnly SameSite , et envoyez le corps (sans signature) au client pour le stocker dans localStorage < / code> et soumettez-le dans l'en-tête Authorization . Lorsque vous autorisez une requête, combinez les deux dans le JWT complet et validez-le comme d'habitude par la suite.
Alternativement, vous pouvez générer deux JWT avec un champ pour les distinguer (par exemple, le client contient "browser" , le cookie contient "cookie" ) et exigent que les deux soient valides et que les deux identifient le même utilisateur. L'un est envoyé dans l'en-tête Authorization et stocké dans localStorage et l'autre utilise le cookie SameSite HttpOnly .
Une autre approche populaire consiste à stocker un jeton CSRF dans un champ du JWT, à placer le JWT dans un cookie et à demander au client d'envoyer un jeton correspondant dans un en-tête (par exemple X-CSRF-Token ).
Toutes les solutions empêchent efficacement les attaques XSS et CSRF: XSS ne peut pas récupérer le cookie HttpOnly, et CSRF n'inclut pas l'en-tête HTTP, donc cela bloque les deux attaques.
Notez que vous ne souhaitez probablement appliquer cette règle qu'aux requêtes des navigateurs Web. Pour la communication de serveur à serveur, les demandes ne sont pas soumises aux attaques CSRF et XSS.
Vous pouvez utiliser jwt est une norme Internet pour créer des jetons d'accès basés sur JSON qui revendiquent un certain nombre de revendications. Par exemple, un serveur peut générer un jeton avec la revendication «connecté en tant qu'administrateur» et le fournir à un client. Le client peut ensuite utiliser ce jeton pour prouver qu'il est connecté en tant qu'administrateur.
Comment ça marche?
D'abord, il contient la clé privée générée par le développeur:
laissez-nous cette clé: sfcqw @ sav% $ # fvcxv * s_s515 et celle-ci appelée privée key, et nous avons également une clé publique, la clé publique générée dépendait des données utilisateur et de la clé privée et il est impossible de savoir ce qu'il contient si vous ne connaissez pas la clé privée.
pour plus d'explications:
clé publique:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.plpJkAcgrgCIsoRyV2kjGsvWF6OsXU1mD785OSWTH4o
nous avons la clé ci-dessus générée par notre clé privée: sfcqw @ sav% $ # fvcxv * s_s515
Pour être plus clair sur ce site Web: https://jwt.io/ et essayez de passer la clé publique sans mettez la clé de secrite comme l'image et vous comprendrez tout.
Pour moi, il n'y avait aucun moyen d'empêcher l'accès au jeton JWT volé sauf
My-X-Auth = Bearer au lieu de Authorization = Bearer X-Content-Security-Policy . En savoir plus Après avoir lutté avec diverses approches, nous avons trouvé une solution expliquée ci-dessous:
Solution: -> Bien que les valeurs de jeton aient été cryptées, elles ne représentaient qu'une seule valeur, donc si on remplace la valeur cryptée entière par une autre valeur cryptée valide, elle peut être piratée.
Pour résoudre ce problème, nous avons ajouté un autre cookie qui était une combinaison de plusieurs valeurs.
Par exemple
Cookie 1 -> jeton chiffré
Cookie 2 -> Un objet crypté contenant des informations comme le nom d'utilisateur + quelques autres détails du contexte utilisateur + un jeton
Donc, dans le cas du cookie 1, il était facile de le remplacer par une autre valeur chiffrée car elle ne représentait qu'un seul jeton bien qu'il soit chiffré.
Mais dans le cas du cookie 2, il contenait un objet avec plusieurs valeurs, donc seule la valeur du jeton ne peut pas être modifiée, chiffrée et replacée dans le même cookie.
Avant l'authentification Nous sommes en train de déchiffrer tout le cookie 2, d'extraire une partie du jeton et de valider la partie de jeton contre le cookie 1.
Cela a résolu notre problème !!
Merci à tous pour votre temps et vos conseils.
Quel est le modèle de menace ici? Comment un jeton serait-il volé puis abusé?
@root Token est stocké dans les cookies côté client, il est possible que certains autres sites Web utilisés via le navigateur puissent récupérer ces cookies.
Le navigateur n'autorise pas n'importe quel site à accéder aux cookies de tout autre site. Pour voler des cookies, vous avez besoin de quelque chose de plus important, par exemple. XSS persistant.