Forge the Tier: Escalating Entitlements With an Unverified JWT Claim
O desafio
Esta plataforma de IA escolhe qual modelo você pode chamar a partir da claim tier dentro do seu JWT. Você está no tier gratuito, mas o backend confia nessa claim sem nunca verificar a assinatura do token. Na bancada, edite o payload para que tier vire enterprise. O token se reconstrói ao vivo. Copie o token forjado inteiro e envie.
O que você vai aprender
- Understand that tier and plan claims gate features only if the token is verified
- Tamper a payload claim and watch the token re-encode in real time
- Forge an entitlement-escalated token by setting tier to enterprise
- Recognise client-trusted claims as a billing and authorization flaw
- Know that entitlements should be checked server-side, not read from a client token
Habilidades testadas
Pré-requisitos
- A JWT is three base64url parts: header, payload, signature
- Entitlement claims like tier and plan live in the payload
- Basic JSON editing
Como funciona
Many products map a billing tier to features: read the tier claim from the user's token and decide which model, rate limit, or capability to grant. That is safe only when the token's signature has been verified, because the signature is the one thing that proves the claim was issued by the server and not edited by the holder. This backend skips verification, so the proof is missing.
With no signature check, the JWT is just a base64url-encoded list of claims you can rewrite at will. The feature gate keys on tier, so you change "tier":"free" to "tier":"enterprise". The workbench re-encodes the payload and rebuilds the token; the original signature is carried along unchanged and is now mathematically wrong, but since the server never checks it, the forged token is accepted and the enterprise model unlocks.
The deeper issue is trusting a client-held value for an authorization or billing decision. Even a perfectly signed token can drift from the real account state, which is why sensitive entitlements are best confirmed against server-side records.
Erros comuns
- Only decoding the token. Reading
tierproves nothing - the bug is that you can change it and still be trusted. - Editing the wrong field. The gate reads
tier; set it toenterprise, notmodeloruser. - Trying to fix the signature. You do not need a valid signature here; the server never verifies it.
- Submitting the decoded JSON. Submit the rebuilt token (or its payload segment), not the human-readable claims.
Como se proteger
Verify the signature before reading any claim, and treat entitlement as server-side state rather than a client-supplied value.
- Verify the JWT signature with the expected algorithm and key on every request; reject
alg:none. - Confirm tier and plan against an authoritative server-side record (the billing system), not just the token claim.
- Keep tokens short-lived so a stale or forged entitlement cannot persist.
- Log and alert on tokens whose claimed tier does not match the account, which surfaces tampering attempts.