In this post we will walk step by step through how to solve JWT authentication bypass via weak signing key on PortSwigger. This lab’s difficulty is Practitioner and it is the third lab on JSON web tokens on Portswigger.

Link to lab: https://portswigger.net/web-security/jwt/lab-jwt-authentication-bypass-via-weak-signing-key

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.

From top to bottom we have the JWS Header, Payload, and Signature.

In JWT Editor click Attack at the bottom left.

Now select Weak HMAC secret. We are going to brute force the secret.

It should now attempt to brute-force the signature.

We were successful and found secret is “secret1“.

Our next goal is to create a forged signing key.

From here we need to select the JWT Editor tab. Now click the button New Symmetric Key.

In the dialog insert secret1 in the Specify secret field, then click Generate to create our key. Now select OK.

Back in Repeater our next step will be to update the “sub” claim from wiener to administrator in the payload.

Finally we need to Sign our JWT by clicking the Sign button.

Now select the newly created Signing Key and keep the “Don’t modify header” checked. Then click OK.

After updating the “sub” claim to administrator and signing our tampered JWT we can try accessing /admin.

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

After deleting the user Carlos with our updated JWT we have successfully solved the lab!

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