WIZER CTF #20: API AUTHENTICATION GATEWAY

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 #20

Goal

In this challenge, we're identifying a simple type of URL Parsing Confusion vulnerability.

Description of code

The code below showcases an API Gateway which is responsible for authentication and relaying calls to an internal API. The internal API isn't performing authentication, since it relies on the Gateway authentication process for endpoints which are defined as `require-authentication`. The code maintains a list of endpoints which require authentication, and based on that list, it determines whether a request should be relayed to the internal endpoint after authentication or should skip it. The internal API isn't accessible externally and can be invoked via the Gateway only, for that purpose, the Gateway exposes a single endpoint named `/callApi`.

What’s wrong with that approach?

The method of validating which request needs to go through authentication isn't tight enough and a potential attacker could trick the system and bypass the authentication for endpoints which actually require it.

What would a successful URL Parsing Confusion attack look like in this case?

An attacker could identify a bypass which returns false for the `if` condition below, but is still a valid endpoint name that could successfully invoke the API within the `else` part of the condition (the `else' part is responsible to relay the call skipping authentication).

For instance, such a bypass would be adding a `/` at the end of the endpoint name, which would be considered as a different endpoint name, but still valid for the internal API.

So what?

URL Parsing Confusion exists in the wild! ...and whether it is there to support a transition process from an old system to a new system or an attempt to implement proper separation of concerns, it isn't always tightly implemented and tested. The consequences of such a vulnerability could be as severe as complete takeover when API endpoints' logic could be skipped or bypassed.

Main Takeaways:

• Avoid separating the authentication and authorization process from the critical functionality:
  Keep the validation of the authentication and authorization process as close as possible to the critical functionality. In this case, the developer could have implemented the authentication process within the internal API itself. If the separation is a must, make sure that the validation is tight enough to prevent bypasses.
• Always prefer allowlists over denylists:
  Instead of defining a list of endpoints that require authentication, it's better to define a list of endpoints that are `allowed` meaning that they don't require authentication. This way, firstly, bypassing that allowlist will just categorize the method as more strict (in this case requires authentication) and secondly, if a new endpoint is added, it will be automatically protected by the authentication process unless it's explicitly allowed. In other words, if the `if` condition was checking for `allowed` rather than `require-authentication` endpoints, the bypass would have been prevented.
• URL Parsing could be very tricky:
  As a rule of thumb, basing critical logic on URL parsing could be very tricky and should be avoided. In this case, to straighten the trust between the pieces, the developer could have used a different approach to ensure that authentication actually occurred, such as passing an encrypted token in the request from the Gateway to the internal API which in turn could validate it and ensure that the request was indeed authenticated.

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

CODE WIZER!

Past Challenges

CTFs For Developers