Forge the Group Claim: Escalating to Admin via cognito:groups
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 etes 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 chaines, gardez donc les crochets et les guillemets intacts. Copiez tout le jeton forgé et soumettez-le.
Ce que tu vas apprendre
- Understand how cloud providers embed group membership in JWT claims
- Edit a nested array claim while keeping the JSON structurally valid
- Forge admin access by changing cognito:groups from users to admins
- Recognise unverified group claims as a critical authorization flaw
- Know that authorization must derive from a signature-verified token
Compétences testées
Prérequis
- A JWT is three base64url parts: header, payload, signature
- Claims can be nested, including arrays of strings
- Basic JSON editing
Comment ça marche
Cloud identity systems such as Amazon Cognito attach a user's groups to their token as a nested claim, conventionally cognito:groups, whose value is an array of group names. Applications then map those groups to permissions: if the array contains admins, grant admin. This works only when the token's signature has been verified against the identity provider's key, because that verification is what proves the group list came from the provider and was not edited by the holder.
This backend reads the array but never verifies the signature, so the JWT is just editable JSON. The challenge over a flat claim is that the target is nested and structured: {"cognito:groups":["users"]}. You must change ["users"] to ["admins"] while keeping it a valid JSON array of strings - the square brackets and the double quotes around the string have to stay, or the payload will not parse. The workbench re-encodes the corrected payload and rebuilds the token, carrying the original (now invalid) signature, which the server ignores.
The result is a token that claims membership in admins and is accepted as such. The flaw is identical in spirit to a flat role forge - the only added difficulty is editing nested structure cleanly.
Erreurs fréquentes
- Breaking the JSON structure.
cognito:groupsis an array of strings; keep the brackets and quotes, for example["admins"], notadminsbare. - Editing the wrong claim. Authorization keys on the group array, not on
suboremail. - Trying to fix the signature. No valid signature is needed here; the server never verifies it.
- Submitting the decoded JSON. Submit the rebuilt, re-encoded token (or its payload segment), not the human-readable claims.
Comment s'en protéger
Group-based authorization is only as strong as the token verification behind it. Verify first, then trust the claim.
- Verify the JWT signature against the identity provider's published key (JWKS) before reading any group claim, and reject
alg:none. - Confirm the token's issuer and audience match your application so a token minted elsewhere cannot be replayed.
- Re-check group membership against the provider for sensitive admin actions rather than trusting a long-lived cached claim.
- Keep tokens short-lived and log privilege-sensitive actions so a forged group is detectable.