Security 101 for Java: CWE-22 Path Traversal
When you’re new to coding, everything is great. You write and write, attend new courses, see other people work to improve yourself, and constantly explore new frameworks, patterns, languages, etc.
But if you have a good mentor or attend a more focused course, they will teach you an important lesson — before changing languages, approaching patterns, or exploring frameworks, you should know the basics and common problems you will encounter while developing solutions. You obviously can’t know every problem or bug that can occur when coding. But, by exploring solutions, talking with others, and using the right tools, you can improve tremendously.
My CWE-22 story started some years ago when I had to develop a Java software to digitize a medical clinic as part of my software engineering course in college.
This software needed to be a simple demo because the purpose of the exam was to project the software correctly and then try to implement a significant part of it using the correct principles. What some of my colleagues didn’t realize was that not all the inputs should be trusted.
One of the software features was dynamic management for some documents. You could archive them using a convenient interface and get them back later by asking for the path you picked. And that was it — the devil was hiding behind the details!
The Bug, the Vulnerability and the Escalation
Let’s take the mask off the bug and look at what it is. Path traversal is a common problem when someone is suboptimally handling relative paths. It consists of putting a path using relative dots to get to another path in the filesystem. If you want to get a more formal definition, you can check out the OWASP Foundation page about it. I’ll keep it easy here.
Imagine being a user called user2 in your system and having a directory structure like this:
This is a common directory structure for a Linux distribution. If you’re a Windows user, it will look similar apart from “/home/user2” becoming like “C:\Users\user2”.
Running a list command will give you the files in the folder.
When looking at the list, you will notice two special files, ‘.’ and ‘..’. They mean this folder and upper folder, respectively. So, if you get into ./test_files, it will open the test_files folder, but if you get into ‘..’, it will move to the folder out of the project.
This means that if a user inputs a path and that path isn’t correctly checked, they can get into folders to which they shouldn’t have access, like ‘etc’, by traversing folder to folder until its prohibited destination. For example, from the project directory to the etc folder, a user should traverse ../../../../../../../etc.
Let’s understand this better with some code.
In this code, users should have access only to the test_files folder as per the developer, writing the correct path to the files like in this execution.
And this is correct. The file contains three lines with a “1” for each line.
But if the user is more imaginative, they can put the input to traverse the path to the passwd file, for example.
And the damage is done. The ‘..’ caused it to traverse to the root directory and take the passwd file. There are some truly terrifying possibilities of what an attacker can do with the passwd file?
Get Safer with a Fix
Fortunately, this bug can be fixed by simply checking where the user is going. If you know the user should move “down a certain path” only, why would you let them climb up? The simpler thing to do is check if the path the user has input is a trusted path.
You can read that the fix is quite easy, but let’s take an extended look at it. The first thing that’s changed is the initialization of a trusted path that will be used later for our “security check”. We want to “normalize” all the paths given as input by translating relative paths to absolute paths. Doing this translation allows us to check if the absolute path given has the same starting part as our trusted path.
Our trusted path will be something like /home/user2/Desktop/Projects/test/cwe-22/test_files. So, once we input our bad path, it will be translated to /etc/passwd, which has nothing except the initial ‘/’ in common with our trusted path. This will make the while condition true, and the program will ask for a clean path.
And here’s the output of the project after a run. As you can see, the bug is corrected, and the vulnerability isn’t there anymore!
Continuous Fixing
CWE-22 is quite easy to fix, but what about something like CWE-502 — Deserialization of Untrusted Data. You may not have even heard about this CWE and probably have no idea of when and how it can get you. This is where two great free tools come in: GitHub and WhiteSource Cure.
Many developers put their code on GitHub, but not everyone knows all of GitHub’s features. It has a lot of cool workflows, like CI/CD and issue management, which can make your life easier.
WhiteSource Cure, on the other hand, helps you by providing fixes for bugs in your GitHub Repository. How do you connect the two? You use a SARIF file.
SARIF stands for Static Analysis Results Interchange Format. It’s a file that static analysis tools give you as an output to communicate the result of the scan with attached metadata. Popular static analyzers that provide you this SARIF file are PVS-Studio and detekt. You can also use a continuous security tool like LGTM. When you’ve got your SARIF file, you just have to open WhiteSource Cure and see your bugs and how to fix them.
The interface is extremely intuitive. Put your repository URL and SARIF file if you’re not using LGTM and click “Fix it!”.
But let’s check why it is so important in a project that’s a little bigger. If you take a look at the LGTM page for WhiteGoat, you can see lots of errors, including CWE-22.
This is quite useful when you effectively know how to fix every bug. And, of course, you can spend a lot of time studying to fix every single bug and CWE affecting your project. But, before you decide on that, shift your focus onto the same project page on WhiteSource Cure.
The page shows the same bug related to CWE-22 but with a major difference: they offer you a quick way to fix the bug on the right side.
Their fixes use their own library, CureKit, available on GitHub under the Apache 2.0 license. Sounds great, doesn’t it?
Stay Away from Insecurities
We’re currently living in an era where cybersecurity is part of our daily routine. I’ve seen many stories about data leaks, code leaks, bugs, and many other issues being used by bad attackers for their own personal gain. But, if you grow daily by learning more about cybersecurity and using the right tools to discover and fix your bugs, the internet will become a more secure place!
