Path traversal: reading forbidden files

The principle

Many sites open a file whose name depends on a parameter: app.example.com/download?file=guide.pdf. In theory, only files from the intended folder are served.

But if the site naively pastes the supplied name into a path, the attacker writes ../../../../etc/passwd. Each ../ goes up one folder. With enough “climbs”, they leave the public folder and reach system files.

What an attacker gains

Configuration files, plaintext passwords, API keys, source code: anything sitting on the server becomes readable. On some platforms this can even lead to code execution (via log poisoning or wrappers).

It falls under OWASP’s A01:2021 – Broken Access Control, because the flaw is about reaching what should stay out of reach.

How to protect yourself

Ideally, never build a file path from the visitor’s text. Map an identifier to a file server-side (1 → guide.pdf) and reject everything else.

If you must accept a name, keep only the basename, forbid “../” and absolute paths, then verify the resolved path stays inside the allowed folder. Keep secrets out of the web root.

The subtlety of detection

This flaw is often “blind”: the site doesn’t display the file, but behaves differently depending on whether it exists. SauronSec compares the response for a real system file and for a non-existent one of the same shape.

A stable, reproducible difference proves the application does resolve the supplied path — without ever reading or exfiltrating any content. Detection, not exploitation: the non-destructive line we hold on principle.