🔓 JWT Authentication Bypass: Exploiting Unverified Signature for Bug Bounty

Author: Aditya Bhatt
Category: Bug Bounty / Web Security / JWT Exploitation
Lab: JWT authentication bypass via unverified signature

---

🔍 Introduction

JSON Web Tokens (JWTs) are widely used for stateless authentication. They are compact, URL-safe tokens that encapsulate claims used to validate a user’s identity. However, when poorly implemented, they become a prime target for attackers.

In this lab from PortSwigger's Web Security Academy, we exploit a critical JWT implementation flaw where the server fails to verify the token’s signature — enabling us to forge arbitrary tokens and impersonate users, including the administrator.

---

🔐 Understanding JWT: A Quick Primer

A JWT (JSON Web Token) consists of three base64-encoded parts, separated by dots:

<Header>.<Payload>.<Signature>

1. Header

Specifies metadata, usually the signing algorithm:

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload

Contains the actual data (claims), such as user identity or role:

{
  "sub": "wiener",
  "admin": false
}

3. Signature

Used to verify that the token was not tampered with. It’s generated by hashing the header and payload with a secret key:

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

📌 If the signature isn’t verified, anyone can change the payload and impersonate users — which is exactly the vulnerability we’ll exploit in this lab.

---

🎯 Lab Objective

Exploit the JWT vulnerability to access the /admin panel and delete the user carlos.

---

🛠️ Tools Used

• Burp Suite
• PortSwigger Lab
• JWT Inspector
• Browser Dev Tools

---

⚙️ Vulnerability Overview

This lab uses JWT for session management. However, due to a critical misconfiguration, the server does not verify the signature of incoming JWTs. This means we can manipulate the payload freely without worrying about the integrity or authenticity checks — a severe logic flaw.

---

🧪 Proof of Concept (PoC): Step-by-Step

1. Access the Lab Visit: JWT Auth Bypass via Unverified Signature Login with the credentials:

   Username: wiener  
   Password: peter  
   

2. Intercept /admin Request After logging in, try accessing /admin. The response should say:

   "Admin interface only available if logged in as an administrator"

3. Analyze the JWT Token Open Burp → Go to Proxy → HTTP History → Find the GET /my-account request. Locate the session cookie, which is a JWT.

   JWT Structure:

   eyJhbGciOi... (header). eyJzdWIiOiJ3aWVuZXIi... (payload). signature
   

   Decode the payload, you’ll see:

   {
     "sub": "wiener",
     ...
   }

4. Modify sub Claim Send this request to Burp Repeater, change the path to /admin. Now, in the Inspector panel, edit the JWT payload: Change "sub": "wiener" → "sub": "administrator" Click Apply changes.

5. Send the Modified Request Send the request. If the implementation doesn’t verify the signature, you’ll be granted admin access. 🎉 Admin panel unlocked!

6. Trigger the Final Exploit Look in the response for a URL like:

   /admin/delete?username=carlos
   

   Send this request to Burp Repeater, or right-click and "Request in browser", then paste the modified JWT in Storage > Cookies if needed.

   ✅ User carlos deleted. Lab solved.

   
   

---

🧠 Why This Works

JWT tokens are composed of three parts:

• Header: Specifies algorithm (e.g., HS256)
• Payload: Contains claims (e.g., sub, exp)
• Signature: Ensures integrity and authenticity

If the server doesn’t verify the signature, an attacker can:

• Modify the payload (e.g., set sub: administrator)
• Skip regenerating a valid signature — because it’s not being checked!

This bypasses authentication entirely — a textbook example of a critical logic flaw.

---

🛡️ Real-World Implications

This vulnerability is often found in:

• Custom JWT libraries or homegrown implementations
• Misconfigured JWT validation on backend servers
• Forgotten security checks in microservices using JWT-based SSO

Impact:

• Account takeover
• Privilege escalation
• Unauthorized access to internal admin panels or APIs

---

🛡️ Prevention & Mitigation

1. Always verify the signature using a secure, vetted JWT library.
2. Never trust JWT payloads without validation.
3. Use asymmetric signing (RS256) with proper key management to avoid shared secret leakage.
4. Implement access control based on server-side verification — not on client-provided claims.

---

🧵 Final Thoughts

JWTs are powerful, but with great power comes great responsibility. This lab elegantly demonstrates how overlooking basic signature verification can open the floodgates to full compromise.

If you're hunting bugs, always inspect tokens — you might find gold in a base64 string.

Happy Hacking! 🐞

---

📚 References

• JWT Debugger
• PortSwigger JWT Labs
• OWASP JWT Cheat Sheet