If you're a returning visitor to our CTF Recaps, feel free to dive straight into the insights! For first-time explorers, let us quickly introduce you to the essence of these recaps. Wizer CTFs were introduced to challenge developers, encouraging them to adopt a hacker's mindset and thereby code more securely. This initiative is a pivotal part of our new security awareness training, specially crafted for development teams - Wizer's Secure Code Training for Developers!

After a challenge retires, our Wizer Wizard and CTO, Itzik Spitzen, crafts takeaways that offer valuable insights into the challenge, focusing on the defensive perspective for your script. Curious to test-drive a CTF before delving into the notes? Visit wizer-ctf.com – it's free, and there's something for all skill levels!

Link to challenge #18


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 `admin=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.


Wanna join us on our next challenge? Sign up for our mailing list at wizer-ctf.com.


Past Challenges

CTFs For Developers