The lab

here is how portswigger describes it

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

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

this kicks off a new class of bug after the template injection series, but the underlying sin is the same one that powered those labs, trusting user input in a place that was never meant to take it.

what path traversal actually is?#

path traversal, sometimes called directory traversal, is what happens when an application builds a file path out of user input without checking it. lots of sites read files off disk to show them to you, product images being the classic example. somewhere in the code the app takes a filename you handed over and sticks it onto a folder path, then opens whatever that points at.

the trouble is the ../ sequence. on a file system .. means go up one directory, so if the app lets your filename contain ../ you can walk up out of the folder it meant to keep you in and back down into anywhere on the disk. feed it enough ../ to reach the root and then name a sensitive file, and the app reads that file for you as if it were a harmless image. /etc/passwd is the traditional target because it exists on every linux box and proves you have escaped the intended directory.

Step 1 - Find where the app reads a file from disk#

upon accessing the lab we just see a product catalogue, nothing obviously interesting on the surface.

clicking into any product gives us the image and some details. the image is the part worth staring at, because an image is a file the server has to fetch and hand back, which is exactly the kind of operation path traversal lives in.

looking at how the image loads, it comes through an endpoint that names the file directly:

/image?filename=22.jpg

that filename parameter is the whole game. the app is clearly taking that value and reading the matching file off disk, so the question is whether it checks the value before using it.

Step 2 - Climb out of the image folder to /etc/passwd#

to test it we intercept the image request in burp and tamper with the filename parameter instead of giving it a real image name.

the images presumably live a few folders deep, so we chain several ../ to climb back up to the root of the file system, then point at the target file:

GET /image?filename=../../../../../../etc/passwd

each ../ steps us up one directory. we do not need to know exactly how deep the image folder sits, because once we are already at the root, extra ../ sequences just stay there and do no harm, so stacking a generous handful of them is a safe way to guarantee we reach the top before walking down into /etc/passwd.

the server does no checking at all, so it resolves that path and returns the file.

the response is the full contents of /etc/passwd, which means we read a file far outside the image directory.

with this, the lab is solved!