🧪 Labs › File System
Local File Inclusion (LFI)
Severity: High
A file path built from your input can be walked out of its intended folder.
What it is
When an app includes or serves a file whose path comes from user input, and doesn't constrain that path, you can traverse out of the intended directory with ../ sequences and reach files elsewhere on the disk.
At minimum you read sensitive files (configs, credentials, source). Depending on how the file is used, LFI can sometimes be chained toward code execution.
The root cause is trusting user input to name a file.
How to approach it
- Find a parameter that names a file — a template, a language, a page, a download.
- Test whether traversal sequences change which file is served, and how the app normalises the path.
- Work toward a known-sensitive file to prove the read, then reason about what the disclosed contents enable.
- Consider filters in the way and whether they're complete.
Your task
Read a sensitive file outside the web root through the file parameter.
▶ Access the labOpens your hosted RatCTF instance. Work on it directly — there's nothing to submit here; you'll know when you've solved it.
How to prevent it
- Don't build file paths from user input; map inputs to a fixed allowlist of files.
- Canonicalise and validate any path, and confine access to a safe base directory.
- Run the app with least privilege so a read can't reach everything.
More File System labs
- Unrestricted File Upload — An upload that trusts the filename or the content type can become code on the server.
- Log Poisoning (LFI → RCE) — Write attacker text into a log the server will later include, and a file read becomes code execution.