What is a JSON Web Token?

A JWT is a compact, URL-safe token that encodes claims in three base64url-encoded sections: header.payload.signature. The header specifies the algorithm, the payload carries the claims, and the signature proves integrity. The critical assumption: the server trusts the algorithm specified in the header. When that trust is misplaced, everything falls apart.

Attack 1: The alg:none Bypass

The JWT specification allows for an "unsecured" token with alg: "none" — meaning no signature is required. Early JWT libraries that accepted this value allowed attackers to forge arbitrary tokens: json { "alg": "none", "typ": "JWT" } Payload: Just remove the signature section entirely, or leave it blank. Fix: Explicitly allowlist permitted algorithms in your JWT validation library. Never accept none.`

Attack 2: RS256 → HS256 Algorithm Confusion

This is one of the most elegant attacks in modern web security. RS256 uses asymmetric keys — a private key to sign, a public key to verify. HS256 uses a single symmetric key for both. The attack: 1. Obtain the server''s public key (often exposed at/jwks.jsonor in documentation) 2. Craft a token with headeralg: "HS256" 3. Sign it with the public key as the HMAC secret 4. The vulnerable server, switching to HS256 verification mode, uses the public key to verify — and it matches! ```bash

Example with odivex-tools

odivex-tools jwt --crack "eyJhbG..." --technique alg-confusion --pubkey server.pem ``` Fix: Require algorithm to be specified server-side during token validation, never from the token itself.

Attack 3: Weak Secret Cracking

Many HS256 deployments use short or guessable secrets. The signature is just an HMAC — brute-forceable offline. ```bash odivex-tools jwt --decode "eyJhbG..." odivex-tools jwt --crack "eyJhbG..." --wordlist /usr/share/wordlists/rockyou.txt ``` Common weak secrets found in the wild:secret, password, jwt, 1234, app name.

Exploitation Checklist

| Attack | Condition | Impact | |--------|-----------|--------| | alg:none | Library accepts none algorithm | Auth bypass | | Algorithm confusion | Public key exposed, asymmetric→symmetric | Auth bypass | | Weak secret | Short/guessable HMAC secret | Token forgery | | Header injection | kid/jku not validated | Key substitution |

Remediation

• Validate algorithm server-side — never from the token

• Use a strong (256-bit+) random secret for HS256

• Prefer RS256 or ES256 for stateless tokens at scale

• Set short expiry (exp`) and implement token rotation