How Paths Resolve

Every traversal payload is an application of four rules. None of them is subtle, and knowing them is the difference between counting ../ by trial and error and knowing how many you need.

1. A path starting with / is absolute. Anything the application prepended is irrelevant — unless it prepended it as a string, in which case the result is no longer absolute. That distinction is the whole of rule 4.
2. .. removes the previous component. It is textual, applied left to right, and it does not care whether the intermediate directories exist.
3. .. at the root is a no-op. /../../.. is /. This is why over-padding is free and under-padding fails — always pad.
4. Repeated separators and . collapse. a//b, a/./b and a/b are the same path.

If the sink takes your input unmodified, skip the traversal entirely:

?page=/etc/passwd

This is worth trying first, always. It is shorter, it survives filters that only look for .., and if it works it tells you immediately that nothing is being prepended.

If a prefix is concatenated, an absolute path does not help in PHP, Node, Java or Go — 'pages/' . '/etc/passwd' is 'pages//etc/passwd', which collapses to pages/etc/passwd by rule 4.

But in Python and .NET it does, and this is the single most valuable runtime-specific fact on this page:

os.path.join('templates', '/etc/passwd')   # -> '/etc/passwd'

Path.Combine("templates", "/etc/passwd")   // -> "/etc/passwd"

Both discard the first argument entirely when the second is absolute. An application that carefully builds a safe base directory and then joins user input onto it has, in those two runtimes, built nothing at all. See Python and ASP.NET Core.

realpath() resolves .., ., repeated separators and symlinks, returning the canonical path — or false if the file does not exist.

That last clause is why the correct pattern is to resolve first and check second:

$real = realpath($base . '/' . $page);
if ($real === false || !str_starts_with($real, $base)) { /* reject */ }

Checking the input string instead of the resolved path is the mistake that every bypass on this site exists to exploit. A string check has to anticipate every encoding; a resolved-path check has to anticipate nothing, because resolution has already happened.

Symlinks are the reason a string check fails even against an opponent who never encodes anything. If an upload directory inside the app tree contains a symlink pointing at /, then uploads/link/etc/passwd contains no .. at all and still leaves the tree. realpath() catches it. str_replace('../', '') does not.

The cost of doing it correctly is that realpath() returns false for a file that does not exist, so the check rejects nonexistent files. That is usually correct behaviour and occasionally a bug report from a developer who wanted a 404 instead of a 400.

The lab implements exactly these rules and shows you the path at each stage of the pipeline. Three things worth doing there:

• Send ../../../etc/passwd with no defences and watch it resolve. Then add ../ and confirm the extra ones cost nothing.
• Turn on str_replace('../', '') and send ....//....//....//etc/passwd. Watch the filter construct the traversal it was meant to remove.
• Turn on realpath() + prefix check and try every payload on the page. This is the one that holds.

The last of those is the point of the exercise. Every encoding in Encoding Bypasses targets a string check. None of them targets resolution, because resolution cannot be tricked by spelling.