The lab

here is how portswigger describes it

This lab contains a path traversal vulnerability in the display of product images.

The application blocks traversal sequences but treats the supplied filename as being relative to a default working directory.

To solve the lab, retrieve the contents of the /etc/passwd file.

the last lab let ../ sail straight through. this one has noticed that trick and started blocking it, so we need a different way to point at a file outside the image folder, one that never uses ../ at all.

why an absolute path gets through ?#

in the simple case we climbed out of the image directory with ../ sequences. the fix most developers reach for first is to look for those sequences in the input and reject or strip them. that stops the climbing trick, but it often misses the other way of naming a file.

there are two ways to write a path. a relative path like 22.jpg is read starting from whatever folder the app is working in, and that is where ../ matters because it walks up from that starting point. an absolute path like /etc/passwd ignores the working directory completely and starts from the root of the file system. it does not contain a single ../, so a filter that only hunts for traversal sequences sees nothing to block, yet an absolute path still points anywhere on disk we like. the lab description even tells us the app treats our filename as relative to a working directory, which is the hint that a leading slash will break us out of it.

Step 1 - Send an absolute path to the image endpoint#

the description makes the location obvious, so we go straight to the image loading endpoint, intercept it, and send it to repeater to work on.

last time the payload was a pile of ../ sequences. this time we drop them entirely and hand over an absolute path instead:

GET /image?filename=/etc/passwd

the leading / is the whole trick. it tells the system to start from the root rather than from the image folder, so there is no traversal sequence for the filter to catch, and the path still lands directly on the target file.

because the filter is only watching for ../ and our payload has none, the request passes straight through and the server reads the file.

the response comes back with the full contents of /etc/passwd.

with this, the lab is solved!