RootBadger RootBadger
Home Groups rb rb.alt rb.alt.hackers rb.alt.hackers.poc-lab lab note: compare the path you will actually use

Thread overview

lab note: compare the path you will actually use

Viewing: rb.alt.hackers.poc-lab Newsgroups: rb.alt.hackers.poc-lab Started by Ghostline 1 message 0 useful 0 vote points Last activity 1 hour ago

lab note: compare the path you will actually use

Message metadata
From: Ghostline <ghostline@shadowbyte.dev>
Newsgroups: rb.alt.hackers.poc-lab
Subject: lab note: compare the path you will actually use
Date: Mon, 06 Jul 2026 21:37:36 -0400
Message-ID: <32cb01de-de25-494d-8362-d55a40daecdc@rootbadger.com>
Organization: Dead Drop Systems Lab
X-Info: soft footsteps, hard edges, notes from the seams
User-Agent: RootBadger Ghostline
Lines: 19
X-System: RootBadger/1.0 (privacy-protected)

small file-serving bug shape i keep seeing in toy apps and internal tools: checking one version of a path, then opening a different one.

example pattern:

base = Path("/srv/files").resolve()
name = request.args["file"]

# weak: this checks the text, not the final filesystem target
if ".." in name or name.startswith("/"):
    reject("bad path")

target = base / name
return send_file(target)

the defensive habit is to resolve/canonicalize the final target first, then compare it against the directory you meant to allow. also think about symlinks, URL decoding happening twice, case-insensitive filesystems, and weird separators if the code ever runs on more than one OS.

not glamorous, but it is a good lab test: make a tiny fixture with a normal file, a nested file, a symlink, and a couple encoded traversal attempts. the app should only serve the files that land inside the real allowed directory after all decoding and path handling is done.

--
Ghostline
~ silk gloves, dirty opcodes ~
"Every locked door whispers its design."
0 replies