La revendication dans la revendication : décoder un profil d'appareil caché dans la charge utile
Le défi
Un terminal portable d'un magasin Brightloom a encaissé un panier bien en dessous du prix affiché, et l'audit montre que la remise a été appliquée par le logiciel de caisse et non saisie par quelqu'un. La revendication scope de l'appareil indique qu'il peut lire le catalogue et enregistrer une vente, rien de plus, et le collègue qui le tenait n'a aucun droit de remise sur son propre compte. Le droit ne vient pas de la personne. Il est dans le jeton du terminal, un niveau plus bas que là où tout le monde a regardé. Donnez la remise, en pourcentage, à laquelle cet appareil a silencieusement droit.
Ce que tu vas apprendre
- Reconnaître un document encodé intégré dans une revendication de token
- Décoder une valeur base64 imbriquée et en lire la structure
- Convertir des points de base en pourcentage
- Expliquer pourquoi deux sources de droits dans un même token finissent par se contredire
- Décrire pourquoi intégrer un profil dans un token le rend public pour le porteur
Compétences testées
Prérequis
- Ce qu'est un JWT et le fait que sa charge utile est encodée, pas chiffrée
Comment ça marche
La charge utile d'un JWT est du JSON, et les valeurs JSON sont des chaînes de caractères. Rien n'empêche un service de placer un second document entier dans l'une de ces chaînes, encodé en base64, et beaucoup le font : un profil d'appareil, un jeu de feature flags, une session sérialisée venue d'un ancien système. Le décodage externe vous montre l'enveloppe, et si vous vous arrêtez là, la moitié intéressante reste une longue ligne opaque qui ressemble à quelque chose que vous n'êtes pas censé lire.
Ce n'est pas le cas. Le base64 est un encodage de transport. Quiconque détient le token détient le profil, en entier, et sur un terminal partagé en magasin, cela représente un public large. Tout ce qui est intégré ainsi doit être traité comme publié.
Le problème le plus profond est d'avoir deux réponses à une même question. scope indique que l'appareil peut lire et vendre. ctx indique qu'il s'agit d'un niveau collègue avec un droit de trente pour cent et des drapeaux de dérogation de prix. Les deux sont signés, les deux sont authentiques, et celui que lit un chemin de code donné est celui que ce chemin applique. Les autorisations doivent se trouver à un seul endroit que chaque contrôle consulte, pas dans une revendication que les contrôles ignorent et que l'application croit.
Erreurs fréquentes
- Répondre 3000. C'est la valeur de
discount_bps. Les points de base sont des centièmes de pour cent, donc c'est 30. - S'arrêter à la revendication scope.
pos.read pos.saleest vrai, et c'est justement pour cela que personne n'a cherché plus loin. - Prendre ctx pour la signature. La signature est le troisième segment, après le second point.
ctxest une valeur à l'intérieur de la charge utile. - Répondre avec un nom de drapeau.
pos.price_overrideest la façon dont la remise est appliquée, mais l'intitulé demande le pourcentage. - Répondre h.mbatha. C'est la personne pour qui le terminal a été provisionné, pas ce à quoi il a droit.
Comment s'en protéger
Placez les droits à un seul endroit et gardez les secrets entièrement hors des tokens.
- Exprimez les autorisations uniquement dans
scope, et faites en sorte que la caisse déduise chaque décision à partir de là. Si un appareil a besoin d'un droit de remise, c'est là qu'il doit se trouver, là où les contrôles peuvent le voir. - N'intégrez pas de profils dans les tokens porteurs. Référencez-les par id et résolvez-les côté serveur, de sorte que le terminal transporte un pointeur plutôt qu'un document.
- Gardez l'autorité de remise sur la personne, pas sur le terminal. Un appareil qui accorde trente pour cent à quiconque le prend en main survit à chaque changement de personnel et à chaque équipe.
- Rapprochez chaque nuit les remises appliquées de l'identité qui les autorise. Une remise sans collègue approbateur est une requête d'une ligne et aurait permis de détecter le problème dès le premier panier.