JWTs (JSON Web Tokens) are a popular method of managing authentication in web applications. They’re compact, stateless, and easy to work with. But what makes them powerful also makes them dangerous — especially when devs get lazy with how they’re validated.

In this article, I’ll walk through a PortSwigger lab involving JWT authentication bypass via jku header injection. Here, a misconfigured server trusts the jku parameter blindly, allowing attackers to specify their own JWK Set URL and forge tokens.

🔍 Quick Primer

• JWK (JSON Web Key): Represents a cryptographic public key used to verify JWTs.
• JKU (JWK Set URL): A JWT header parameter that tells the server where to fetch a public key.
• KID (Key ID): Identifies which key in the JWK Set should be used for signature verification.

If a server trusts the jku blindly, an attacker can:

• Host their own public key,
• Sign tokens with their private key,
• And make the server happily verify it like it’s legit.

• Lab Title: JWT Authentication Bypass via JKU Header Injection
• Goal: Forge a JWT with a malicious jku header to access /admin as an admin and delete user carlos.
• Vulnerability: Server fetches and trusts public keys from attacker-controlled jku URLs without validation.

The jku header tells the server where to fetch a JWK Set. If the app doesn't validate the source domain, it's open season for attackers to serve their own keys and impersonate users — even admins.

🛠 Prerequisite: Install the JWT Editor extension in Burp Suite before starting.

🧭 Background: Install JWT Editor Extension

✅ Step-by-Step

1. Access the lab and login with credentials: wiener:peter

2. Attempt to access /admin. You’ll see:

• Admin interface only available if logged in as an administrator.

3. Capture the /admin request and send it to Burp Repeater.

4. In JWT Editor, create a New RSA Key, then Generate a random keypair.

5. Go to the Exploit Server and enter this minimal JWK Set:

{ "keys": [] }

6. Back in JWT Editor, Right-click your generated key > Copy Public Key as JWK and paste it into the keys array. Final JSON:

{ "keys":
  [
    { "kty": "RSA",
      "e": "AQAB",
      "kid": "dce97972–8493–46ef-844b-342b7984fe25",
       "n": "…" }
  ]
}

7. Return to the JWT request in Repeater, open the JSON Web Token tab, and:

• Change sub from wiener to administrator
• Set the kid to the copied key’s kid

8. Add the jku parameter in the JWT header with the hosted JWK Set URL:

"jku": "https://exploit-<your-id>.exploit-server.net/exploit"

9. Click Sign > select the generated RSA key > choose Don’t modify the header.

10. Send the request. 🎉 Boom! You now have admin access.

11. Change the path to /admin/delete?username=carlos and send it to complete the lab.

12. Confirm lab completion via the browser link — mission accomplished!

This flaw is straight-up privilege escalation. If left unchecked, any attacker can impersonate any user — just by pointing the server to their malicious key set.

In real-world apps, this can lead to full takeover of admin panels, user accounts, or sensitive APIs.

• ✅ Whitelist trusted domains for jku
• 🚫 Avoid remote key fetching unless absolutely necessary
• 🔐 Use strict JWT library settings to disallow unknown key sources
• 🔁 Layer in additional auth checks beyond JWTs

This lab is a classic case of “don’t trust user input” — even if it’s hiding in a JWT header. A simple oversight in key validation turned token-based auth into a red carpet for attackers.

Always verify the source of your JWKs. Never let users decide how you validate their identity. That’s like letting them write their own passport and stamp it too.

Until next time — Hack Smart, Stay Sharp and Question Everything. 🧠💥

🗿 Peace out.