Understanding JSON Web Token Vulnerabilities | TryHackMe Walkthrough

If you build or audit web auth, this short TryHackMe walkthrough is worth a read. It explains two practical JWT attack patterns you’ll see in CTFs , and sometimes in the wild:

Changing the alg to HS256 (signature forgery)
- Some servers accept the alg in the token header. If a token originally uses RS256 (RSA), an attacker who can access the server’s public key can trick the server into verifying with HMAC (HS256) instead — letting them compute a valid signature themselves and tamper with claims (e.g., role: user → role: admin).
alg: none (signature removed)
- Decode header+payload, set "alg":"none", modify payload, re-encode and drop the signature. If the server trusts alg:none, it will accept the token without verifying a signature.

Why this matters: JWTs themselves are fine when implemented correctly , but insecure server-side handling (trusting the token’s alg, or shipping public keys improperly) opens serious auth bypasses. The walkthrough includes demo steps and CTF flags.

Source / walkthrough: https://motasem-notes.net/understanding-json-web-token-vulnerabilities-tryhackme/ motasem-notes.net

Defensive checklist (quick):

Never trust client-controlled alg without server-side enforcement.
Prefer asymmetric signing (RS*/ES*) with strict server-side verification of the expected algorithm.
Validate token issuer (iss), audience (aud), expiry (exp) and claims.
Rotate and protect keys; avoid exposing private keys.
Use well-tested libraries and follow their secure defaults.