Folder Traversal: What It Means & How to Stop It

Folder traversal (also called path traversal or directory traversal) is a web attack where a user manipulates a URL or file path to read files outside the web server’s intended directory. It happens when the server fails to validate user-supplied file paths, letting an attacker access files like passwords, source code, or system configuration. Preventing it requires strict input validation, using safe file-access APIs, and configuring the server to deny suspicious path patterns.

Background: Why Folder Traversal Exists

Web servers are built to serve files from a specific folder, usually called the document root or web root. When you request https://example.com/images/logo.png, the server maps that URL to /var/www/html/images/logo.png on disk. The server’s job is to keep all file access inside that root folder.

Problems arise when an application needs to let users specify a file name or path dynamically. For instance, a site might let you view a report by visiting https://example.com/view.php?file=report.pdf. The PHP code behind it might do something like:

readfile('/var/www/html/reports/' . $_GET['file']);

If the server does not check the file parameter, an attacker can send ?file=../../etc/passwd. The ../ sequence moves up one directory level, so the final path becomes /var/www/html/reports/../../etc/passwd, which normalizes to /etc/passwd. The server happily reads and displays the password file. This is the core of folder traversal.

How Folder Traversal Works

Attackers use a few standard techniques to break out of the web root:

• Dot-dot-slash: ../../etc/passwd or ..\..\windows\win.ini on Windows.
• Encoded characters: Servers often decode URL encoding before processing. %2e%2e%2f is ../, and %252e%252e%252f is double-encoded, which can bypass naive filters.
• Absolute paths: If the application does not check for a leading slash, file=/etc/passwd may work directly.
• Alternate separators: Windows accepts both / and \, so ..\..\ might slip through a filter that only blocks ../.
• Null bytes: In older PHP versions, file=../../etc/passwd%00.jpg would truncate the string at the null byte, bypassing an extension check.

The impact ranges from reading sensitive files (like /etc/passwd, database credentials, or application source code) to, in some misconfigured cases, writing files or executing code. The classic example is reading ../../../../etc/passwd on a Linux server, which reveals user names and sometimes other system details.

How to Prevent Folder Traversal

Prevention is straightforward if you follow a layered approach. No single fix is perfect, so combine several:

1. Use a whitelist of allowed file names. If the application only needs to serve report1.pdf through report5.pdf, accept only those exact strings. Reject everything else.
2. Validate the input against a strict pattern. For example, allow only [a-zA-Z0-9_]+ and reject any character outside that set. This blocks ../, \, and encoded variants automatically.
3. Canonicalize the path and check its prefix. After resolving the full path (using a function like realpath() in PHP or Path.GetFullPath() in .NET), verify that the resolved path starts with the intended base directory. If it does not, reject the request.
4. Use the server’s built-in file-serving mechanisms. Do not write custom file-reading code if you can avoid it. For static files, let the web server (Apache, Nginx, IIS) handle the mapping. For downloads, use a database ID or a random token instead of a file path.
5. Disable unnecessary features. Turn off directory listing, disable mod_autoindex in Apache, and ensure the application runs with the least privilege needed. The web server user should not have read access to system files.
6. Apply security updates. Old versions of web servers, PHP, and application frameworks have had traversal vulnerabilities. Keep everything patched.

Common Mistakes That Leave You Vulnerable

Even with good intentions, developers often make mistakes that reintroduce the flaw:

• Filtering only ../: Attackers can use ....// (which normalizes to ../ after one filter pass), URL encoding, or backslashes on Windows.
• Checking the input but not the resolved path: A filter might block ../, but an absolute path like /etc/passwd still works if the application prepends a base directory.
• Using file_exists() or is_file() before validation: These functions follow symlinks and can reveal information even if you later block the read.
• Trusting the operating system to handle .. safely: Some filesystems or archive extraction tools allow .. in file names, which can cause traversal when files are later served.
• Ignoring the database: If a file path is stored in a database and later used without validation, an attacker who can inject into that field can cause traversal.

Comparing Folder Traversal to Other Web Attacks

Folder traversal is often confused with two similar attacks:

• Local File Inclusion (LFI): LFI is a type of folder traversal where the attacker includes a local file into the application’s output, often to execute PHP code or leak source code. The difference is that LFI usually targets the application’s own files, while folder traversal can target any file the server can read.
• Path Traversal vs. Symlink Attack: A symlink attack creates a symbolic link inside the web root that points to a sensitive file outside. This is a server misconfiguration or a result of an upload vulnerability, not a URL manipulation.
• Directory Traversal vs. Directory Listing: Directory listing is when the server shows all files in a folder. It is not an attack itself, but it can help an attacker find files to target with traversal.

Understanding these differences helps you choose the right defense. For example, blocking ../ alone will not stop an LFI that uses a PHP wrapper like php://filter.

Testing Your Own Server

If you administer a web server, you can test for folder traversal safely on your own system:

1. Create a test file outside the web root, e.g., /tmp/test.txt on Linux or C:\temp\test.txt on Windows.
2. Try requesting it through your application using various path patterns: ../../../../tmp/test.txt, %2e%2e%2f%2e%2e%2f, and absolute paths.
3. Check the response. If you see the file content, you have a vulnerability.
4. Use a web vulnerability scanner (like OWASP ZAP) to automate the test, but only on systems you own or have written permission to test.

Remember that a single test with one encoding does not prove safety. Attackers will try dozens of variations. The only robust defense is the canonicalization check described earlier.

Frequently Asked Questions

What is the difference between folder traversal and path traversal?

They are the same thing. “Folder traversal,” “path traversal,” and “directory traversal” all refer to the same vulnerability where an attacker uses ../ or similar sequences to escape the web root. The term “directory traversal” is more common in OWASP and CVE reports.

Can folder traversal be exploited without a vulnerable application?

Yes, but it is rare. Some web servers have had built-in traversal bugs (e.g., IIS in the late 1990s with ..%5c). Modern, patched servers are generally safe. The vulnerability almost always comes from custom application code that reads user input as a file path.

Does using a framework like Django or Rails automatically prevent folder traversal?

Frameworks provide safe file-serving functions, but they do not make you immune. If you write custom code that takes a user-supplied path and passes it to open() or readfile(), you can still be vulnerable. Always use the framework’s file-serving utilities and validate input.

What is the most common real-world example of folder traversal?

The most cited example is reading /etc/passwd on Linux. This file contains user account names and sometimes hashed passwords (though modern systems keep hashes in /etc/shadow). In web applications, attackers often target configuration files like .env or web.config that contain database credentials.

Can folder traversal lead to remote code execution?

Directly, no. Folder traversal only reads or writes files. However, if the attacker can write a file (e.g., into a temp directory that is later executed), or if they can read source code to find another vulnerability, it can lead to code execution. The php://input or data:// wrappers in LFI can sometimes execute code directly.

Is URL encoding enough to bypass a filter?

Yes, if the filter is not decoding the input first. A common mistake is to check the raw URL for ../ but then decode it before using it. Double encoding (%252e) can also bypass filters that decode only once. The safest approach is to decode and canonicalize the path, then check the result.

Related

• Data Center On-Site Power: What to Evaluate
• Search Engine Rank: Meaning & How Google Orders Results
• Stop Enhanced Notifications Waking Mac Sleep?