Skip to content


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,

Where 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:

If 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.


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:



In the same way, you can also replace “../” with an empty string. Pay attention to cover all cases, even something like this:



A lot of filters only match and replace the first subset string “../” and don’t check again.



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!



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

As part of our mission to secure the world’s OT, IoT and Cyber Physical infrastructures, we invest resources into offensive research of vulnerabilities and attack techniques.

Ripple20 are 19 vulnerabilities revealed by Israeli firm JSOF that affect millions of OT and IOT devices. The vulnerabilities reside in a TCP/IP stack developed by Treck, Inc. The TCP/IP stack is widely used by manufacturers in the OT and IoT industries and thus affects a tremendous amount of devices.

Among the affected devices are Cisco Routers, HP Printers, Digi IoT devices, PLCs by Rockwell Automation and many more. Official advisories by companies who confirmed having affected devices can be found here, in the “More Information” section.

The most critical vulnerabilities are three that can cause a stable Remote Code Execution (CVE-2020-11896, CVE-2020-11897, CVE-2020-11901) and another that can cause the target device’s memory heap to be leaked (CVE-2020-11898).

On behalf of our customers, we set out to explore the real impact of these vulnerabilities, which we’re now sharing with the public.

The research has been conducted by researchers Maayan Fishelov and Dan Haim, and has been managed by SCADAfence’s Co-Founder and CTO, Ofer Shaked.

Exploitability Research
We set out to check the exploitability of these vulnerabilities, starting with CVE-2020-11898 (the heap memory leak vulnerability), one of the 19 published vulnerabilities.

We created a Python POC script that is based on JSOF official whitepaper for this vulnerability. According to JSOF, the implementation is very similar to CVE-2020-11896, which is an RCE vulnerability that is described in the whitepaper. Also mentioned about the RCE vulnerability: “Variants of this Issue can be triggered to cause a Denial of Service or a persistent Denial of Service, requiring a hard reset.”

Trial Results:
Test 1 target: Samsung ProXpress printer model SL-M4070FR firmware version V4.00.02.18 MAY-08-2017. This device is vulnerable according to the HP Advisory.

Test 1 result: The printer’s network crashed and required a hard reset to recover. We were unable to reproduce the heap memory leak as described, and this vulnerability would have been tagged as unauthenticated remote DoS instead, on this specific printer.

Test 2 target: HP printer model M130fw. This device is vulnerable according to the HP Advisory.

Test 2 result: Although reported as vulnerable by the manufacturer, we were unable to reproduce the vulnerability, and we believe that this device isn’t affected by this vulnerability. We believe that’s because the IPinIP feature isn’t enabled on this printer, which we’ve verified with a specially crafted packet.

Test 3 target: Undisclosed at this stage due to disclosure guidelines. We will reveal this finding in the near future.

Test 3 result: We found an unreported vendor and device, on which we can use CVE-2020-11898 to remotely leak 368 bytes from the device’s heap, disclosing sensitive information. No patch is available for this device. Due to our strict policy of using Google’s Responsible Disclosure, we’ve reported this to the manufacturer, to allow them to make a patch available prior to the publication date.

Key Takeaways
We’ve confirmed the exploitability vulnerabilities on our IoT lab devices.

On the negative side: The vulnerabilities exist on additional products that are unknown to the public. Attackers are likely to use this information gap to attack networks.
On the positive side: Some devices that are reported as affected by the manufacturers are actually not affected, or are affected by other vulnerabilities. It might require attackers to tailor their exploits to specific products, increasing the cost of exploitation, and prevent them from using the vulnerability on products that are reported as vulnerable.

SCADAfence Research Recommendations
Check your asset inventory and vulnerability assessment solutions for unpatched products affected by Ripple20.
The SCADAfence Platform creates an asset inventory with product and software versions passively and actively, and allows you to manage your CVEs across all embedded and Windows devices.
Prioritize patching or other mitigation measures based on: Exposure to the internet, exposure to insecure networks (business LAN and others), criticality of the asset.
This prioritization can automatically be obtained from tools such as the SCADAfence Platform.
Detect exploitation based on network traffic analysis.
The SCADAfence Platform detects usage of these exploits in network activity by searching for patterns that indicate usage of this vulnerability in the TCP/IP communications.
If you have any questions or concerns about Ripple20, please contact us and we’ll be happy to assist you and share our knowledge with you or with your security experts.

About Version 2 Limited
Version 2 Limited is one of the most dynamic IT companies in Asia. The company develops and distributes IT products for Internet and IP-based networks, including communication systems, Internet software, security, network, and media products. Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 Limited 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, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.

About SCADAfence
SCADAfence helps companies with large-scale operational technology (OT) networks embrace the benefits of industrial IoT by reducing cyber risks and mitigating operational threats. Our non-intrusive platform provides full coverage of large-scale networks, offering best-in-class detection accuracy, asset discovery and user experience. The platform seamlessly integrates OT security within existing security operations, bridging the IT/OT convergence gap. SCADAfence secures OT networks in manufacturing, building management and critical infrastructure industries. We deliver security and visibility for some of world’s most complex OT networks, including Europe’s largest manufacturing facility. With SCADAfence, companies can operate securely, reliably and efficiently as they go through the digital transformation journey.