Falsifier la revendication de groupe : élévation vers admin via cognito:groups

Sécurité Cloud Niveau 4/4 ~7 min 18 août 2026

Le défi

Cette application cloud autorise les actions d'administration à partir d'une revendication de groupe imbriquée dans votre JWT, le tableau cognito:groups de style Cognito. Vous êtes dans le groupe users, mais le backend lit ce tableau directement depuis le jeton et ne vérifie jamais la signature. Dans l'atelier, modifiez la charge utile pour que cognito:groups devienne ["admins"]. Attention au JSON : c'est un tableau de chaînes, gardez donc les crochets et les guillemets intacts. Copiez tout le jeton forgé et soumettez-le.

Ce que tu vas apprendre

  • Comprendre comment les fournisseurs cloud intègrent l'appartenance à un groupe dans les revendications JWT
  • Modifier une revendication tableau imbriquée tout en gardant un JSON structurellement valide
  • Falsifier l'accès admin en changeant cognito:groups de users à admins
  • Identifier les revendications de groupe non vérifiées comme une faille critique d'autorisation
  • Savoir que l'autorisation doit provenir d'un jeton dont la signature a été vérifiée

Compétences testées

Falsification de JWTTest d'autorisation cloudManipulation de revendications imbriquéesÉlévation de privilèges

Prérequis

  • Un JWT comporte trois parties en base64url : en-tête, charge utile, signature
  • Les revendications peuvent être imbriquées, y compris des tableaux de chaînes
  • Notions de base d'édition JSON

Comment ça marche

Les systèmes d'identité cloud comme Amazon Cognito attachent les groupes d'un utilisateur à son jeton sous forme de revendication imbriquée, classiquement cognito:groups, dont la valeur est un tableau de noms de groupes. Les applications associent ensuite ces groupes à des permissions : si le tableau contient admins, l'accès admin est accordé. Cela ne fonctionne que si la signature du jeton a été vérifiée avec la clé du fournisseur d'identité, car c'est cette vérification qui prouve que la liste des groupes provient bien du fournisseur et n'a pas été modifiée par le détenteur.

Ce backend lit le tableau mais ne vérifie jamais la signature, donc le JWT n'est qu'un JSON modifiable. La difficulté par rapport à une revendication plate est que la cible est ici imbriquée et structurée : {"cognito:groups":["users"]}. Vous devez changer ["users"] en ["admins"] tout en gardant un tableau JSON valide de chaînes : les crochets et les guillemets autour de la chaine doivent rester, sinon la charge utile ne pourra pas être analysée. L'atelier ré-encode la charge utile corrigée et reconstruit le jeton, en conservant la signature d'origine (désormais invalide), que le serveur ignore.

Le résultat est un jeton qui revendique l'appartenance au groupe admins et qui est accepté comme tel. La faille est identique dans l'esprit à une falsification de rôle plat : la seule difficulté supplémentaire est d'éditer proprement une structure imbriquée.

Erreurs fréquentes

  • Casser la structure JSON. cognito:groups est un tableau de chaines ; gardez les crochets et les guillemets, par exemple ["admins"], et non admins tout seul.
  • Modifier la mauvaise revendication. L'autorisation dépend du tableau de groupes, pas de sub ou email.
  • Essayer de corriger la signature. Aucune signature valide n'est nécessaire ici ; le serveur ne la vérifie jamais.
  • Soumettre le JSON décodé. Soumettez le jeton reconstruit et ré-encodé (ou son segment de charge utile), pas les revendications lisibles.

Comment s'en protéger

L'autorisation basée sur les groupes n'est jamais plus solide que la vérification du jeton qui la sous-tend. Vérifiez d'abord, faites confiance à la revendication ensuite.

  • Vérifiez la signature du JWT avec la clé publiée par le fournisseur d'identité (JWKS) avant de lire toute revendication de groupe, et rejetez alg:none.
  • Confirmez que l'émetteur et l'audience du jeton correspondent à votre application, afin qu'un jeton émis ailleurs ne puisse pas être rejoué.
  • Revérifiez l'appartenance aux groupes auprès du fournisseur pour les actions admin sensibles, plutôt que de faire confiance à une revendication mise en cache de longue durée.
  • Gardez des jetons à courte durée de vie et journalisez les actions sensibles en matière de privilèges afin qu'un groupe falsifié soit détectable.

Solution complète

Les membres Pro et Max débloquent la solution complète étape par étape.

Passer Pro

Statistiques de la communauté

108 résolutions
72% taux de réussite
M2F14M3 Premier sang

Hacks du jour associés

24 000+ Hackers 100+ Labs & Cours Gratuit
Commencer Gratuitement