Wizer CTF #18: Registration and Login

Link to challenge: CTF #18

Goal

In this challenge, we're identifying a JWT Token exploit caused by insecure secret management.

Description of code

The code below showcases the typical registration, login and profile parts of an app. It is using a JWT token to send the session details back and forth between the browser and the server. The token has a signature, with means that the server can verify the integrity of the session data using that signature. The profile endpoint determines whether the user is an admin or a simple user based on an `admin` field which is encrypted within the JWT Token.

What’s wrong with that approach?

Simple: the JWT encryption password is included as clear-text within the code. Leaving keys in the code is dangerous, the developer should always assume that potential attackers could get access to it.

What would a successful JWT exploit attack look like in this case?

An attacker who gains access to the source code, could use the password to regenerate a JWT Token containing altered data. In this case, an online tool such as jwt.io could allow us to re-encrypt a token which contains the `isAdmin=true` property to trick the system into identifying

So what?

JWT Token exploits could very well mean "game-over" in terms of account take-over scenarios. Once properties which are assumed encrypted and trusted could be tempered with, the entire reason to use the best practice of a JWT Token collapses.

Main Takeaways:

• Never store keys in your code:
  Always store your keys in a secure location, such as a vault or a secure environment variable. Never store keys in your code, as it could be accessed by potential attackers.
• Make sure that all encryption passwords are strong:
  Always make sure that your encryption passwords are strong and not easily guessable. The longer the password, the better.

Code Wizer!