**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.**
JSON Web Token (JWT) is a lightweight and URL-friendly method for securely sharing data between systems or users. It is widely used in authentication and authorization in modern web apps.
Instead of storing user sessions on the server, JWT stores user identity and claims on the client side, signed using a secret key to ensure integrity.
Structure of a JWT
A JWT has three base64url-encoded parts separated by dots (.):
<Header>.<Payload>.<Signature>
1. Header: Contains metadata like the signing algorithm used:
{
“alg”: “HS256”,
“typ”: “JWT”
}
2. Payload: Contains claims about the user (like username, roles, expiration):
{
“sub”: “wiener”,
“role”: “user”,
“exp”: 1715000000
}
3. Signature: Used to verify the token hasn’t been tampered with:
HMACSHA256(base64url(header) + “.” + base64url(payload), secret)
How JWT Authentication Works
- The client sends credentials.
- If valid, the server creates a signed JWT and returns it.
- The client stores it (usually in cookies or localStorage).
- The client sends the JWT in headers (Authorization: Bearer <token>).
- Server Verifies: The server validates the signature and extracts user claims.
Walkthrough
JWTs are usually signed using a secret or a private key to prevent tampering. However, if the server:
- Doesn’t verify the signature
- Accepts alg: none (no algorithm)
Then, an attacker can modify the payload without needing the secret, and the server will still accept it as valid.
Walkthrough: Bypassing JWT Authentication
- Unverified Signature
Lab: JWT authentication bypass via unverified signature | Web Security Academy
This lab uses a JWT-based mechanism for handling sessions. Due to implementation flaws, the server doesn’t verify the signature of any JWTs that it receives.
To complete the lab, you need to alter your session token in order to unlock access to the admin panel located at /admin. Once inside, your task is to remove the user named Carlos. You can begin by signing into your own account with these credentials: wiener as the username and peter as the password.
Step 0: Log in to the account using the given username and password.
Step 1: Open Burp Suite → Go to Proxy > HTTP History. Look for a GET /my-account request after login. In the Cookie header, you’ll see a JWT token.
Step 2: Double-click the payload part (middle section of the JWT). In the Inspector panel, it decodes to:
{
“sub”: “wiener”
}
sub claim represents the username.
Step 3: Right-click on the request → Send to Repeater.
Step 4: In the Repeater tab, change the request path to:
GET /admin
Send the request. You will likely get a 403 Forbidden or 401 Unauthorized because you’re not an admin.
Step 5: In the JWT, double-click the middle section(payload) again and check the Inspector panel. Then change: “sub”: “wiener” to “sub”: “administrator“. Click Apply changes — this modifies the raw JWT string in the request.
Step 6: Send the request again to /admin. If the server is not verifying the signature, it will accept the tampered JWT, and we will now see the admin panel, meaning the bypass was successful.
Step 7: In the admin panel response, find: /admin/delete?username=carlos endpoint. Send this GET request for this endpoint, and we see a 302 found. This means Carlos’s account is deleted, and the lab is solved.
How Did This Work?
The server decoded the JWT but didn’t verify the signature. That means anyone can modify the payload and impersonate any user. This defeats the entire purpose of JWT’s cryptographic signature.
- Flawed signature verification
Lab: JWT authentication bypass via flawed signature verification | Web Security Academy
In this lab, session management relies on JSON Web Tokens (JWTs). However, the server has a security flaw — it’s set up to accept tokens even if they haven’t been signed.
To solve the lab, modify your session token to gain access to the admin panel at /admin, then delete the user carlos.
Follow the same steps from 0 to 4 as done in above walkthrough. Then follow these steps:
Step1: In the JWT, double click middle section(payload) and check the Inspector panel. Then change:
“sub”: “wiener” to “sub”: “administrator”
Click “Apply changes”. Send the request to /admin endpoint. We still see 401 unauthorized error.
Step 2: In the JWT, double-click the first section(header) and check the Inspector panel. Then change:
“alg”: “HS256” to: “alg”: “none”
Click “Apply changes”.
Step 3: Delete the signature part (after the second dot), but keep the dot.
<header>.<payload>.
Step 4: Send the request again to /admin. If the server accepted a JWT with “alg”: “none” it would accept the tampered JWT, and we would now see the admin panel, meaning the bypass was successful.
Step 5: In the admin panel response, find: /admin/delete?username=carlos endpoint. Send this GET request for this endpoint, and we see a 302 found. This means Carlos’s account is deleted, and the lab is once again solved.
Conclusion
In both scenarios, we demonstrated critical flaws in JWT implementation that allowed us to bypass authentication and gain unauthorized access to protected functionality.
- In the first scenario, the server decoded the JWT but failed to verify its signature. This allowed us to manipulate the payload (e.g., changing the sub claim to administrator) and access privileged areas like the admin panel, despite not having a valid signature.
- In the second scenario, the server was misconfigured to accept tokens with “alg”: “none” — effectively disabling signature verification altogether. By removing the signature and modifying the payload, we were again able to forge a valid-looking JWT and escalate privileges.
These vulnerabilities highlight the importance of strict JWT signature verification and the dangers of misconfigured or insecure token handling.
