In JWTs, the alg header defines which algorithm is used to sign and verify the token. Typically, asymmetric algorithms like RS256 are used where the server uses a private key to sign and a public key to verify.

But if the server blindly trusts the alg header and doesn’t enforce strict validation... 👀 We can switch it to HS256, a symmetric algorithm, and use the server’s own public key as the HMAC secret to forge tokens.

And that, my friend, is how you impersonate an admin with just the public key and a sneaky switcheroo. 🧙‍♂️

Lab: JWT Authentication Bypass via Algorithm Confusion Difficulty: Expert Goal: Exploit algorithm confusion in JWT validation to gain admin access and delete user carlos.

Background: Install the JWT Editor extension from Burp Suite’s BApp Store to manipulate tokens easily.

🛠️ Let’s fire it up…

Head over to the lab and log in using the following creds:

Username: wiener  
Password: peter

Manually navigate to /admin. You’ll see a message like:

“Admin interface only available if logged in as an administrator.”

Nothing surprising yet… but that’s about to change. 🧨

Capture the /admin request in Burp and send it to Repeater. We'll soon replace the JWT in this very request.

Now in your browser, visit the JWK endpoint for the server:

https://<your-lab-id>.web-security-academy.net/jwks.json

Copy the key object from the response (leave out the square brackets if it’s in an array):

{"kty":"RSA","e":"AQAB","use":"sig","kid":"8660d963-1b64-4e93-96b2-1bb9fb258620","alg":"RS256","n":"rM3x..."}

In JWT Editor → Keys tab:

• Click New RSA Key
• Paste the copied JWK
• Save it
• Right-click → Copy Public Key as PEM

Now you’ve got a shiny PEM to weaponize. 🧨

Head over to Burp’s Decoder:

• Paste the PEM
• Encode to Base64
• Copy the result

This will be your HMAC secret soon. Yes, really. 😈

Back in JWT Editor → Keys tab again:

• Click New Symmetric Key
• Replace the k value with the Base64-encoded PEM
• Save

Boom — the server’s public key is now our secret. 😎

Back in Repeater → JSON Web Token tab:

• Set "alg" to "HS256"
• Change "sub" to "administrator"
• Click Sign
• Choose the symmetric key created above
• Tick the box Don’t modify the header

You’re now wielding a forged token with god-level access. 🛡️

Hit Send in Repeater.

🎉 SUCCESS! You’re in as the administrator — no private key, no brute force, no noise. Just pure JWT black magic. 🪄💀

Now go ahead and modify the URL to:

/admin/delete?username=carlos

Hit Send.

Poor Carlos never saw it coming 🪦

Right-click → Show in browser → paste the request URL.

You’ll be greeted with a sweet message marking the lab as ✅ SOLVED.

Let’s break it down:

• Server expects RS256
• We send HS256
• Server blindly accepts the alg value
• We use its public key (intended for verification) as the HMAC secret
• 🔐 It verifies the token like a good bot. Game over.

• Auth bypass without private key
• Admin impersonation
• Critical vulnerability
• Fully automatable
• 🧨 High-severity CVSS in real-world apps

• Always enforce strict alg value on the backend
• Disable support for multiple algorithms
• Never trust client-supplied headers for cryptographic decisions
• Use well-tested JWT libraries configured securely

• JWT is not a silver bullet — poor implementation = 💣
• Never mix symmetric + asymmetric algorithms
• If you’re using RS256, treat it like your baby — no HMAC switching allowed
• Read the RFCs — they hide secrets in plain sight

That’s it for Part 6, folks. One more JWT misconfiguration, one more exploit in your red team arsenal. Stay alert, stay curious — and always test the alg header like your next bounty depends on it.

Until next time… keep breaking tokens & taking names.

Let your tokens always validate and your secrets always leak (to you only).