Si vous pouvez décoder JWT comment sont-ils sécurisés?
j'adore JWT, c'est vraiment amusant de travailler avec. Ma question Est, si j'obtiens une JWT et que je peux décoder la charge utile, Comment est-ce Sécurisé? Est-ce que je ne pourrais pas simplement récupérer le jeton de l'en-tête, le décoder et changer les informations de l'utilisateur dans la charge utile et le renvoyer avec le même secret codé correct?
je sais qu'ils doivent être, j'aime juste de comprendre les technologies. Ce qui me manque? Merci!
5 réponses
JWTs peut être signé, crypté ou les deux. Si un jeton est signé, mais non chiffrée, tout le monde peut lire le contenu du jeton, mais quand vous ne connaissez pas la clé privée, vous ne pouvez pas la modifier. Sinon, le destinataire remarquera que la signature ne correspondra plus.
réponse à votre commentaire: Je ne suis pas sûr de comprendre votre commentaire de la bonne façon. Juste pour être sûr: connaissez-vous et comprenez-vous les signatures numériques? Je vais juste expliquer brièvement une variante (HMAC, qui est symétrique, mais il y en a beaucoup d'autres).
supposons Qu'Alice veut envoyer un JWT à Bob. Ils ont tous les deux un secret en commun. Mallory ne connait pas ce secret, mais veut interférer et changer le JWT. Pour éviter cela, Alice calcule Hash(payload + secret) et ajoute ceci comme signature.
lors de la réception du message, Bob peut également calculer Hash(payload + secret) pour vérifier si la signature correspond.
Si, par contre, Mallory change quelque chose en le contenu, elle n'est pas en mesure de calculer la signature correspondante (qui serait Hash(newContent + secret) ). Elle ne sait pas le secret et n'a aucun moyen de le trouver.
Cela signifie que si elle change quelque chose, la signature ne correspondra plus, et Bob n'acceptera plus la JWT.
supposons que j'envoie à une autre personne le message {"id":1} et que je le signe avec Hash(content + secret) . (+ est juste concaténation ici). J'utilise la fonction de hachage SHA256, et la signature que j'obtiens est: 330e7b0775561c6e95797d4dd306a150046e239986f0a1373230fda0235bda8c . Maintenant c'est votre tour: jouer le rôle de Mallory et essayer de signer le message {"id":2} . Tu ne peux pas parce que tu ne sais pas quel secret j'ai utilisé. Si je suppose que le destinataire connaît le secret, il peut calculer la signature de n'importe quel message et vérifier si elle est correcte.
vous pouvez aller à jwt.io , collez votre token et lisez le contenu. C'est choquante pour beaucoup de gens d'abord.
la réponse courte est que JWT ne se préoccupe pas de cryptage. Il se soucie de la validation. C'est-à-dire qu'il peut toujours obtenir la réponse pour "le contenu de ce pion manipulé"? Cela signifie que la manipulation par l'utilisateur du token JWT est futile parce que le serveur connaîtra et ignorera le token. Serveur ajoute une signature basée sur la charge utile lors de l'émission d'un token au client. Plus tard, il vérifie la charge utile et la signature correspondante.
la question logique est Quelle est la motivation pour ne pas se préoccuper de contenu crypté?
-
la raison la plus simple est qu'elle suppose qu'il s'agit d'un problème résolu pour la plupart. Si vous avez affaire à un client comme le navigateur web par exemple, vous pouvez stocker les tokens JWT dans un cookie c'est-à-dire
secure + httpsOnly(ne peut pas être lu par Javascript + ne peut pas être lu par HTTP) et parle au serveur sur un canal crypté (HTTPS). Une fois que vous savez que vous avez un canal sécurisé entre le serveur et le client, vous pouvez échanger JWT en toute sécurité ou n'importe quoi d'autre que vous voulez. -
cela rend les choses simples. Une implémentation simple facilite l'adoption, mais elle permet aussi à chaque couche de faire ce qu'elle fait le mieux (laisser HTTPS gérer le chiffrement).
-
JWT n'est pas destiné à stocker des données sensibles. Une fois que le serveur reçoit le token JWT et le valide, il est libre de rechercher L'identifiant de l'utilisateur dans sa propre base de données pour obtenir des informations supplémentaires pour cet utilisateur (permissions, adresse postale, etc.). Cela maintient JWT petit dans la taille et évite la fuite d'information par inadvertance parce que tout le monde sait ne pas garder les données sensibles dans JWT.
il n'est pas trop différent de la façon dont les cookies eux-mêmes travail. Les Cookies contiennent souvent des charges utiles non cryptées. Si vous utilisez HTTPS, alors tout va bien. Si vous ne l'êtes pas, il est conseillé de crypter les cookies sensibles eux-mêmes. Le fait de ne pas le faire signifie qu'une attaque d'un homme au milieu est possible--un serveur mandataire ou un FAI lit les cookies et les rejoue plus tard en prétendant être vous. Pour des raisons similaires, JWT doit toujours être échangé sur une couche sécurisée comme HTTPS.
les contenus d'un JSON web token (JWT) ne sont pas intrinsèquement sécurisés, mais il existe une fonctionnalité intégrée pour vérifier l'authenticité des tokens. Une JWT est constituée de trois hachures séparées par des périodes. La troisième est la signature. Dans un système de clés publiques / privées, l'émetteur signe la signature symbolique avec une clé privée qui ne peut être vérifiée que par sa clé publique correspondante.
il est important de comprendre la distinction entre émetteur et vérificateur. Le destinataire du jeton responsable de la vérification.
il y a deux étapes critiques pour utiliser JWT de façon sécuritaire dans une application web: 1) les envoyer sur un canal crypté, et 2) Vérifier la signature immédiatement après l'avoir reçue. La nature asymétrique de la cryptographie à clé publique rend la vérification de la signature JWT possible. Une clé publique vérifie qu'une JWT a été signée par sa clé privée correspondante. Aucune autre combinaison de touches ne peut effectuer cette vérification, empêchant ainsi les tentatives d'usurpation. Suivez ces deux étapes et nous pouvons garantir avec certitude mathématique l'authenticité d'une JWT.
plus d'information: comment une clé publique vérifie-t-elle une signature?
seul le privateKey de JWT, qui est sur votre serveur, décryptera le JWT crypté. Ceux qui connaissent privateKey pourront déchiffrer la JWT cryptée.
cachez privateKey dans un endroit sûr de votre serveur et ne dites à personne le privateKey.
les données à L'intérieur de JWT sont signées et cryptées, cela ne signifie pas qu'elles sont sécurisées. JWT ne fournit pas de garantie pour les données sensibles.
les données sont cryptées en utilisant une clé privée qui est connue des deux parties c.-à-d. l'expéditeur et le destinataire, un intrus peut freiner la clé et peut changer le contenu.
à ma connaissance, JWT ne fournit pas de sécurité.
Merci