Forge the Group Claim: Escalating to Admin via cognito:groups
O desafio
Este app na nuvem autoriza ações de admin a partir de uma claim de grupo aninhada no seu JWT, o array cognito:groups no estilo Cognito. Você está no grupo users, mas o backend lê esse array direto do token e nunca verifica a assinatura. Na bancada, edite o payload para que cognito:groups vire ["admins"]. Cuidado com o JSON: é um array de strings, então mantenha os colchetes e as aspas intactos. Copie o token forjado inteiro e envie.
O que você vai aprender
- 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
Habilidades testadas
Pré-requisitos
- A JWT is three base64url parts: header, payload, signature
- Claims can be nested, including arrays of strings
- Basic JSON editing
Como funciona
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.
Erros comuns
- 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.
Como se proteger
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.