Labs Covered

This write-up focuses on the following labs from the PortSwigger Web Security Academy related to JWT (JSON Web Token) vulnerabilities:

1 JWT authentication bypass via unverified signature

This lab demonstrates how attackers can bypass authentication by exploiting JWT implementations that fail to verify the token's signature.

2 JWT authentication bypass via flawed signature verification

This lab shows how attackers can exploit incorrect signature verification logic to bypass authentication.

---

LAB 1 - JWT authentication bypass via unverified signature

Lab Description

Solution

So we try to login as admin

First we use extension which will tell us which is JSON requets,So as we can see in blue the json request login as wiener

The we send myaccount request to repeater and the copy cookie

So I paste thie request in https://token.dev/and see the result and we can manuplate the request in this tool

After manuplating the request we set sub to administrator copy the JWT string

Then copy and paste the above jwt in the session and send to repeater and we can see the admin panel,And method to delete the wiener

Copying and Pasting the method of deleting carlos we can see that the it giving us 302 reponse which means its deleting carlos and then we follow rediretcion And open the session in burp then lab is solved

---

LAB 2 - JWT authentication bypass via flawed signature verification

Lab Description

Overview: Accepting Tokens with No Signature (JWT alg=none Vulnerability)

What is it? A critical JWT vulnerability arises when a server accepts tokens with no cryptographic signature, typically when the token’s header contains:

{ "alg": "none" }

This indicates an “unsecured JWT”, meaning the token is not signed at all — it’s just base64-encoded data that anyone can forge.

---

Why It’s Dangerous

The core flaw lies in trusting unverified, user-supplied input. The alg field tells the server what algorithm to use to verify the token, but this instruction itself is part of the untrusted token.

• The server hasn’t yet validated the token, so blindly accepting alg: none gives the attacker full control over the verification process.

• This can allow an attacker to forge arbitrary tokens by:

  • Setting alg to none
  • Omitting the signature
  • Supplying a fake payload (e.g., escalating privileges to admin)

---

Example Attack

1. Original JWT:

   eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiZ3Vlc3QifQ.SIGNATURE
   

2. Attacker-modified token:

   eyJhbGciOiJub25lIn0.eyJ1c2VyIjoiYWRtaW4ifQ.
   

   • alg is set to none
   • No signature is included
   • The server, if misconfigured, will accept it and treat the user as admin

---

Bypass Techniques

Even if the server appears to reject alg=none, filters may be bypassed using:

• Mixed capitalization: NoNe, NONE
• Unicode/hex/URL encodings
• Tampered headers in base64 (e.g., extra padding or malformed characters)

---

Solution

First we will try to access admin panel but it is giving us admin interface is available administrator

So Iogin as wiener and intercept at back we can see at blue sign which is telling us its valid using extension of burp

As we can see that decoded jwt

Now I change wiener to administrator and copy it

Then I paste the jwt and change id to administrator and paste above jwt token and send requets

After Sending request we can see that I logout It could be that it doesn’t valid what algorithm is being used so we can try to set alg to none

Or we can also try to login as admin but jwt token is not working

It could be that it doesn’t valid what algorithm is being used so we can try to set alg to none But also to add . at the end of payload part

Even if the token is unsigned, the payload part must still be terminated with a trailing dot.

As we can see that after setting algo to 0 and adding tarling charcter . We can login as admin

And after open request in browser we can delete user and then lab is solved

---