JWT authentication bypass via flawed signature verification

In this post we will walk step by step through how to solve JWT authentication bypass via flawed signature verification on PortSwigger. This lab’s difficulty is Apprentice and it is the second lab on JSON web tokens on Portswigger.

Link to lab: https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-flawed-signature-verification

To start the lab click the ‘Access the Lab’ button.

As we begin the lab we encounter a blog showcasing different posts. It’s worth noting that the posts may differ from the screenshot as PortSwigger Labs can vary the content with each lab session. So, don’t worry if your products look different.

Using the credentials provided to us (wiener:peter) we can authenticate into the application and view our account information.

If you do not have the JWT Editor extension installed, you will need to do so under the Extensions tab. At the time of writing this post the JWT Editor extension can be used for Burp Suite Community Edition and Pro Edition.

Navigating back to the Proxy tab we should see green highlighted Requests. This is JWT Editor letting us know a JWT is in this HTTP Request.

Sending the my-account?id=wiener Request to Repeater will allow us to tamper with the JWT by clicking on the JSON Web Token tab.

Our goal for this lab is to get administrative access to the /admin panel and delete the user carlos due to a flawed signature in the JWT.

Using the Attack option in the JWT Editor extension, we can try swapping the algorithm to ‘none’. If the server is vulnerable it might accept the modified token without checking the signature.

In JWT Editor, click Attack at the bottom left.

Now select the “none” Signing Algorithm.

Select the default which is none.

The signature should now be gone.

Let’s update the “sub” from wiener to administrator in the payload and see if this allows us to bypass authentication with no signature.

After updating the “sub” claim to administrator and changing the Header value of “alg” to “none” we can try and access /admin.

Here we see we have access to the /admin panel and can delete the users due to the server not checking the signature of the JWT we provided.

It appears we can delete the user Carlos and solve the lab by navigating to /admin/delete?username=carlos with our updated JWT.

That completes the lab! Well done! If you found this helpful, please send me a tweet and tell me what you thought! Feedback is always appreciated!

Jarrod