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!
Goal
In this challenge, we're identifying a Directory Traversal (a.k.a. Path Traversal). Let's have a look!
Description of code
The code below showcases a UI and an endpoint of a simple "Privacy Policy Viewer''. The UI invokes an API endpoint upon receiving a query argument of the company name, which in turn retrieves the privacy policy file from a dedicated folder named `/privacyPolicies` on the server. Each company is assumed to have a text/html file, named after the company which includes the privacy policy of the company.
What’s wrong with that approach?
In reviewing the code, we can identify a potential Directory Traversal vulnerability of the endpoint. The user input isn't sanitized, and hence, the name of the file which is a user input, could be manipulated to retrieve an unintended file. The following part of the code shows that the `companyName` argument is directly used to specify the filename, and hence could be manipulated:
What would a successful Directory Traversal attack look like in this case?
An attacker could exploit the endpoint (or the UI) to retrieve practically any system file which is within the privileges of the account running the web-server process. For example, the required `passwd` file could be retrieved by specifying `../` multiple times to traverse back to the root folder and then into `/etc/passwd`. The exact number of `../` required to get to the root folder, could be easily discovered by trial and error and in fact specifying a larger than needed number of `../` would still work.
So what?
Directory Traversal allows the attacker to target specific files under the OS, the app and any other system installed on the server to read information and gain unauthorized access to sensitive pieces of information. This could very easily lead to taking full control over the server or alternatively getting data from various configuration files, which could risk other systems as well.
Main Takeaways (credits to PostSwigger article):
- Avoid supplying a filename directly as user-input:
The most effective way to prevent path traversal vulnerabilities is to avoid passing user-supplied input to filesystem APIs altogether. Most application functions that do this can be rewritten to deliver the same behavior in a safer way. In our example, the developer could have used a mapping of company names to file names, then use the company name to retrieve the file name from the mapping, and then use the file name to retrieve the file content. - Remember to sanitize any user-input which participates in a file path:
In case the app functionality absolutely requires it, make sure the input is properly sanitized, by following the steps below:
- Validate the user input before processing it. Ideally, compare the user input with a whitelist of permitted values. If that isn't possible, verify that the input contains only permitted content, such as alphanumeric characters only.
- After validating the supplied input, append the input to the base directory and use a platform filesystem API to canonicalize the path. Verify that the canonicalized path starts with the expected base directory.
Wanna join us on our next challenge? Sign up for our mailing list at wizer-ctf.com.
CODE WIZER!
Past Challenges
