Forge the Tier: Escalating Entitlements With an Unverified JWT Claim
Le défi
Cette plateforme d'IA choisit le modèle que vous pouvez appeler à partir de la revendication tier de votre JWT. Vous êtes sur le niveau gratuit, mais le backend fait confiance à cette revendication sans jamais vérifier la signature du jeton. Dans l'atelier, modifiez la charge utile pour que tier devienne enterprise. Le jeton se reconstruit en direct. Copiez tout le jeton forgé et soumettez-le.
Ce que tu vas apprendre
- 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
Compétences testées
Prérequis
- A JWT is three base64url parts: header, payload, signature
- Entitlement claims like tier and plan live in the payload
- Basic JSON editing
Comment ça marche
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.
Erreurs fréquentes
- 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.
Comment s'en protéger
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.