Path Traversal Defense Lab

Defense mode

Requested path

Sandbox root depth 3

Result

resolved: /var/www/uploads/images/photo.png

200 OK — inside sandbox

Depth vs root

".." segments

Requests sent

Breaches / blocked

0 / 0

How it works

A file server that builds paths by naive string concatenation is vulnerable to directory (path) traversal: it joins the sandbox root with the client-supplied path and opens whatever results, without checking where that path actually ends up.

// vulnerable
open(ROOT + "/" + userPath)

// secure — resolve, then verify containment
resolved = canonicalize(ROOT + "/" + userPath)
if (!resolved.startsWith(ROOT + path.sep)) reject(403)
open(resolved)

Canonicalization walks the path segment by segment on a stack: a normal name pushes a directory, . is a no-op, and .. pops the stack. Feed it enough ../ segments and the stack empties out below the sandbox root — the resulting absolute path points somewhere the application never meant to expose, e.g. /etc/passwd.

Naive concat — the walker is allowed to keep descending past the root floor (shown in red); if it lands on a real file the request returns 200, which is the bug: an attacker just read a file outside the sandbox.
Canonicalize + prefix-check — the exact same resolved path is computed, but before opening anything the server checks that it still starts with the sandbox root. The moment the walker would cross below the root floor, the request is rejected with 403 — the escape never happens.
Real-world equivalents: CVE-class "zip-slip" (archive entries containing ../), unsanitized ?file= query parameters, and FTP/SFTP servers that fail to jail their root.

Sandbox root floor Request walker Outside the sandbox

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.