Lesson 2 of 3 in Path Traversal · 2 min left in this chapter
Read The Secrets Next Door
A real ops console with a log viewer, a real operator login, and a deploy secret sitting one directory above the logs. You will climb out with `..` and read the token the viewer never meant to hand you.
2 min read
Not yet reviewed
The lab for this chapter is an internal operations console — the kind on-call engineers use. It has a log viewer. Sign in, open it, and then ask it for a file that is not a log.
Ask it for something that is not a log. Like what?
Like the deploy secrets that live one folder up from the logs. The viewer will build the path for you the moment you put .. in the name.
Legal
This console is ours and is meant to be broken. Reading files outside a web application's intended directory on a system you do not own or have written permission to test is unauthorised access, and a crime in most countries. The technique is legal to learn; using it without authorisation is not.
Signing in
Open the lab in a new tab — you need a real session, because you will log in and then use the console. Sign in as the operator:
operator ops
password relay2024
- Line 1An ordinary on-call operator account. Exactly the kind of low-privilege foothold from which reading the deploy secrets should not be possible — and, here, is.
The move
Open the log viewer. It offers you log files by name and reads whichever one you ask for. There is only one move, and it is a filename:
../relay-secrets.txt
- Line 1The logs live in a folder; the deploy secrets live beside that folder, one level up.
..climbs out of the logs;relay-secrets.txtnames the file waiting there. The viewer joins the two and reads it.
Now do it
Put ../relay-secrets.txt into the log viewer and read what comes back. Among the deploy configuration is a RELAY_DEPLOY_TOKEN — a secret an operator viewing logs was never meant to see. That token is your flag, and it is unique to you. Submit the one your session shows.
You could also read ../../../../etc/passwd. Why does climbing four directories with .. never overshoot past the top of the filesystem?
/, another .. has nowhere to go and stays at /. That is why attackers pad traversals with more .. than they need — extra ones are harmless, and it means they do not have to know exactly how deep the starting folder is.What actually went wrong
The application built a filesystem path out of a value you controlled and then followed it. There was no check that the resolved path stayed inside the log folder — the confinement lived only in the developer's head, and .. is precisely the sequence that leaves it. The fix is not a better list of bad filenames; it is refusing to let the resolved path escape.