This article will cover some of the best practices to prevent path traversal attacks.
There are many different names for this attack, such as “dot-dot-slash,” “directory traversal,” and “directory climbing.” As you can guess from the name of this attack, targets are folders (directories), files.
This HTTP attack would be successful if the attacker could enter restricted directories and execute malicious commands outside the web server’s root directory.
Example using parameters:
We are storing files in the application (documents in this case). The user would upload the files and choose a name; if successful, they would have access to the stored files (to preview and modify them).
So, in this case, the document is stored in the application, and the user wants to modify it. The HTTP request to access the files on a given system would be done via parameters.
kumarishefu.4507 gives a cool definition for parameters: “Parameters are query parameter strings attached to the URL that could be used to retrieve data or perform actions based on user input”.
For example, if a user wants to access and display their “DocumentOne” within the web application, the request may look as follows,
http://example.com/preview?file=DocumentOne.pdfWhere the file is the parameter and documentOne.pdf is the file, we want to access.
For the attacker, this is important to know because they can use this information to try and do the attack if the input where the user saves (uploads) a file name is not properly sanitized and validated.
Their target is to somehow write to the server’s directory, which could lead to RCE
The image below shows the web application file/folder tree.
If we want to walk through directories (go one step up), we would use “../” – if you remember, this attack is also called “dot-dot-slash.”
How did the attacker use it in the mentioned example?
So, the target is the root directory, and they want to access the files from the /etc/passwd directory.
They would use this URL:
http://example.com/preview?file=../../../../etc/paswdIf the application is susceptible to this attack, they would list all the files in that folder when they execute such URL.
How to prevent access by filtering keywords
Usually, the attacker is interested in the /etc/passwd, /etc/shadow (if available); for example, they could check /etc/group to see if any of the users are listed in the root or wheel groups.
http://example.com/preview?file=../../../../etc/passwd
To prevent accessing sensitive information, you can filter some keywords, for example: /etc/passwd. But be aware that there are 2 ways to bypass these filters. First, by using NullByte (%00); second, by adding “/.” to the end of the filtered keyword. That URL would look like this:
http://example.com/preview?file=../../../../etc/passwd%00or
http://example.com/preview?file=../../../../etc/passwd/.
In the same way, you can also replace “../” with an empty string. Pay attention to cover all cases, even something like this:
....//....//....//....//....//etc/passwd
A lot of filters only match and replace the first subset string “../” and don’t check again.
Summary
You saw that this attack happens because the application doesn’t have proper input validation, and it has access to sensitive data and the ability to write to the server. To prevent directory traversal, we want to cover all bases by writing an application opposite our example above.
Example using Cookies:
In many applications, cookies can access files required for the website. As you can imagine, that can be one way in for the directory traversal attack!
This is not the best practice, but you can set up some security flags on cookies:
- Secure Flags which are preventing the cookie from ever being sent over an unencrypted connection
- HTTPOnly Flag prevents scripts from reading the cookie
- SameSite Flag aims to prevent CSRF attack
- HostOnly Flag specifies if the cookie should be accessible by subdomains
*Note: Use Session cookies if it is possible. If not set an expiration.
*Note for Angular: To set up cookie service and cookie with secure flag you can use ngx-cookie-service package easily:
import { CookieService } from 'ngx-cookie-service';
constructor( private cookieService: CookieService ) { }
ngOnInit(): void {
const secureFlag = true;
this.cookieService.set('cookieName', 'somevalue', 1, ‘/’ , ‘localhost’, secureFlag , "Strict");
}Testing application’s vulnerability:
There are some tests to check the application’s vulnerability to Directory traversal attack, which are recommended by OWASP. You can always write your own automation tests or do them manually, but I recommend using existing testing tools because they cover many different use cases.
- Static application security testing (SAST) – this solution uses the white-box technique. In this case, this means that tests are performed on the application’s source code when it is not running. You can find out more about configuring and using SAST on the Gitlab site.
- Dynamic application security testing (DAST) – this solution uses the black-box technique. The difference between SAST is that these tests don’t need to access the application’s source code. These tests also use Fuzzing. They would simulate a real attack on the frontend of the application while it is running. You can find out more how you can configure and use DAST on the Gitlab site.
There is one blog with a good explanation of why it is best to use both tools to get a complete analysis.
Prevention steps:
- To prevent directory traversal on your web server, always keep your web server and operating system updated.
- Validation of user’s input (pay special attention if the user of the application can give the name of a file – scan it for valid characters)
- The non-admin permissions should be read-only for the files which are used
- All URL requests which are made to manage a directory or file should be checked properly. All characters must be normalized (“%20” should be converted to spaces – for example, using encodeURIComponent() method in JS)
- The web server should be run separately from your system disk. System disk needs to be protected because it has sensitive information
- Implement sandbox environments (for example, chroot) to set boundaries between the processes and the operating system.
File Permissions
It is very important to have one line of defense right before accessing files. To achieve that, you can limit user access by implementing roles and permissions. We can assume that the application already had implemented authentication (such as MSAL, for example, if you are using Azure), so the next step would be authorization. Authorization is the verification process of the user’s access to files, data, etc.
Of course, all code regarding the authorization logic can be written manually, but you can also use some helper packages, such as ngx-permissions (for Angular).
When implementing authorization, we should follow the principle of least privilege. The principle states that users should be assigned the minimum necessary access rights to achieve what’s required. Also, it states that rights should be in effect for the minimum possible duration.
*There is one example of how people found vulnerabilities in angular-HTTP-server-package versions less than 1.4.4 on this blog. So, if you are using an old version of Angular with this version of the package, update it!
Conclusion
The best way to avoid a Directory Traversal attack is to avoid writing the application that takes user input and passes it to APIs system files.
Instead, these application functions can be rewritten to use a safer way.
If it is necessary to pass user input to APIs system files, then use the prevention steps I explained.
In the end, secure code is the cheapest code!
System files paths in Windows and Unix
There is the list of some system files paths provided on-site:
For Unix-based operating systems:
· /etc/passwd file: Contains information about all the user’s account
· /etc/group file: Contains groups to which users belong
· /etc/profile file: Contains default variables for users
· /proc/self/environ file: Contains certain environmental variables
· /etc/issue file: Contains message to be displayed before the login
· /proc/version file: Contains the Linux kernel version in use
· /proc/cpuinfo file: Contains the processor information
For Windows Operating systems:
· C:\Windows\repair\system
· C:\Windows\repair\SAM
· C:\Windows\win.ini
· C:\boot.ini
· C:\Windows\system32\config\AppEvent.Evt
If you want to familiarize yourself more with the Unix filesystem, you can check out the site, and for Windows, you can use this site.
#path_traversal #permissions #cookie_flags #vicarius_blog
Cover photo by Markus Spiske
About Version 2 Digital
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About VRX
VRX is a consolidated vulnerability management platform that protects assets in real time. Its rich, integrated features efficiently pinpoint and remediate the largest risks to your cyber infrastructure. Resolve the most pressing threats with efficient automation features and precise contextual analysis.
The very mention of data governance and compliance can send shivers down the spines of corporate IT professionals, particularly for those who recognize they aren’t ready to handle a major data breach or other situation that compromises mission-critical data.
