Understanding Path Traversal: How Directory Traversal Leads to Arbitrary File Reads

Principle

A file‑download or preview service is intended to read only files inside a designated directory (e.g., ./upload/). The backend builds the final file path by concatenating the base directory with the filename supplied by the client.

How the vulnerability appears

If the backend does not filter special sequences such as ../ (or Windows ..\), the operating system resolves them as “move up one directory”. An attacker can therefore climb out of the allowed folder and read arbitrary files on the server, which is the classic path‑traversal (directory‑traversal) issue.

Typical vulnerable scenarios

File download endpoints (e.g., /download?filename=aaa.pdf)

Online preview services for documents or images

Configuration‑reading APIs and log‑viewing interfaces

Static‑resource loading or template file inclusion

Backend panels that display uploaded images

Whenever the filename is supplied via a URL or POST parameter, the risk is high.

Practical example (Java pseudocode)

/opt/software/
├─ web.jar
├─ upload/          # allowed folder
│   └─ test.jpg
├─ application.yml  # contains DB credentials
└─ etc/
    └─ passwd      # Linux account file

String fileName = request.getParameter("filename");
String fullPath = "./upload/" + fileName;
fileUtil.readFile(fullPath);

Normal request: http://127.0.0.1/download?filename=test.jpg → concatenated path ./upload/test.jpg (safe).

Malicious request: http://127.0.0.1/download?filename=../application.yml → concatenated path ./upload/../application.yml, which the OS resolves to ./application.yml, exposing the database configuration file.

Second payload: filename=../../etc/passwd reads the Linux password file.

Windows variant uses ..\, e.g., download?filename=..\..\windows\system32\drivers\etc\hosts.

URL‑encoded bypasses such as %2E%2E%2F (encoding of ../) survive naïve filtering because some servers decode the value before applying the blacklist.

Potential impact

Reading configuration files (database usernames, passwords, secret keys)

Accessing source code or internal API logic

Retrieving system files like /etc/passwd to enumerate accounts

Combining with other vulnerabilities to gain server‑level privileges

Harvesting log files that contain sensitive business data

Mitigation measures (ordered by effectiveness)

Blacklist filtering – simply removing ../ or ..\. Not recommended because encoding tricks can bypass it.

Whitelist strategy – expose only a fixed list of downloadable files. The client sends a file ID (e.g., ?fileId=1001) and the backend looks up the real filename in a database, eliminating user‑controlled paths.

Canonical‑path validation – after constructing the absolute path, verify that it starts with the allowed base directory (e.g., /opt/software/upload/). If !realPath.startsWith(baseDir), reject the request.

Strict filename character whitelist – allow only alphanumerics, underscores, and periods; reject characters such as ../, \, /, *, :, |, <>.

Front‑end validation – can improve user experience but must not be relied upon because attackers can modify requests directly.

Interview‑ready summary

Cause: user‑controlled filename concatenated with a base path without restricting ../ leads to directory escape.

Attack surface: download or preview endpoints that accept a filename parameter.

Payload: one or multiple ../ sequences (or URL‑encoded equivalents) to read arbitrary files.

Consequences: leakage of configuration, source code, system files, and potential privilege escalation.

Best defense: prioritize ID mapping (whitelist), then canonical‑path checks; avoid simple blacklist filters.