Directory Traversal (CWE: 22) is usually considered a subset of Path Manipulation (CWE: 73). Directory Traversal, also referred to as Path Traversal, attacks occur by manipulating variables with the ‘../’ (dot-dot-slash is another name this attack sometimes goes by) sequences, and attempt to access directories and files stored in a system. Path Directory traversal attacks are usually aimed at gaining access to application source code and critical system files and is placed at #13 on the SANS Top 25 Most Dangerous Software Errors.
Directory Traversal attacks can be aimed at the web server, or the application code, and attacks are successful when neither the root directory or the Access Control Lists correctly restrict user access. The difference between Directory Traversal and other security issues is that while many security issues are caused by coding flaws and holes in the code, Directory Traversal attacks are enabled by a lack of security.
Very often, when I give lectures about application security, I start with a path manipulation example.
Path manipulation vulnerabilities are possible when user-controlled data is put in a URL or file and is saved on the server. Once on the server, an attacker could modify the path and gain access to other files held on server.
I’ve found that while developers can easily understand the risk Directory Traversal and Path Manipulation attacks can pose, it’s relatively complicated to avoid it correctly. This has taught me that discussing this attack gives a great background for discussions on more complicated attacks.
Usually, I begin with a short “hacking game” showing the following VB (6) example (assuming that the Filename and Ext variables are considered as user input)
if (ext <> “exe”) then
Open filename & “.” & ext for output as #1
print #1, “^ CxThoughts blog”
msgbox (”WOW! I found a hacker!”)
Then I ask the students to fix the code so the following rules will apply:
1. The user should be able to create ANY type of file anywhere they want with the content “^ CxThoughts blog”.
2. Only .exe extension is forbidden, and an appropriate message should appear in case of hacking attempt.
Seems simple, ah?
Try to do it yourself, then try to break in, then fix, then break in again… it’s not as easy as it looks.
My guess is that it will be possible to hack into any of your solutions.
Recently I have encountered the following Java code, which should receive a full path name, and return only the filename (e.g. getFilename(”C:trytemp.txt”) = temp.txt)
private String getFilename(String filepath)
String filename = filepath.trim();
int index = filepath.lastIndexOf(File.separator);
if (index > -1)
filename = filepath.substring(index);
What do you think the code ends up doing? Leave your answers below!
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.