🧪 Labs › File System
Unrestricted File Upload
Severity: High
An upload that trusts the filename or the content type can become code on the server.
What it is
File upload turns dangerous when the app trusts attacker-controlled signals — the filename extension, the Content-Type header — to decide what a file is and where it goes.
If an uploaded file lands somewhere the server will execute, and its type isn't properly constrained, an upload becomes server-side code execution. Even without execution, uploads enable stored XSS, overwrite, and path traversal.
The checks are usually present but shallow: a blocklist of extensions, a client-side filter, a Content-Type that the client sets.
How to approach it
- Upload a benign file and learn where it's stored and how it's served back.
- Probe how the type is decided — extension, declared Content-Type, magic bytes — and which of those you control.
- Test the completeness of any filter (case, double extensions, alternate names) and whether the stored path is where it's served from.
- Reason about what the server does with a file of the type you can smuggle through.
Your task
Get a file the application shouldn't accept into a location where it matters.
▶ 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
- Validate type by content, not by filename or client Content-Type; store with a generated name and a safe extension.
- Serve uploads from a location that never executes, ideally a different origin.
- Enforce size and type allowlists server-side.
More File System labs
- Local File Inclusion (LFI) — A file path built from your input can be walked out of its intended folder.
- Log Poisoning (LFI → RCE) — Write attacker text into a log the server will later include, and a file read becomes code execution.