DML Injection

INSERT · UPDATE · DELETE — Beyond SELECT
05.05 · SQL Injection

Not All Injection Targets SELECT

Most SQL injection tutorials focus on extracting data through SELECT queries. But real web applications run INSERT, UPDATE, and DELETE statements constantly—every registration form, profile editor, and "delete my account" button is a potential injection point.

DML injection is often more dangerous than data theft because it lets attackers:

WARNING: DML injection modifies data. A single successful attack can corrupt entire tables, create undetectable backdoor accounts, or wipe production databases.
LAB 01

Rogue Registration

Acme Corp's new user registration page inserts your details into the users table. The application hardcodes the role as 'user' in the query. Can you register yourself as an admin instead?

INSERT INTO users (username, email, role) VALUES ('[USERNAME]', '[EMAIL]', 'user')
CHALLENGE

Register a new account, but manipulate the query so your role becomes 'admin' instead of 'user'.

users table
IDUsernameEmailRole

Think about closing the VALUES clause early. If you control the email field, you can inject hacker@evil.com', 'admin') --

The closing ' ends the email string, then 'admin') replaces the hardcoded 'user' value, and -- comments out the rest.

This attack works because the INSERT statement concatenates user input without parameterization. The attacker closes the VALUES clause on their own terms and injects the role value they want. Parameterized queries would have treated the entire email field as a single string value, making the injection impossible.

LAB 02

Privilege Escalation

You're logged in as user jsmith (ID 3). The "Edit Your Profile" page lets you change your email address. The application only updates the email column... or does it?

UPDATE users SET email='[INPUT]' WHERE id=3
CHALLENGE

Change your role to 'admin' by injecting through the email update field. You are user ID 3.

users table (before)
IDUsernameEmailRole

You can inject additional SET clauses. Try: hacked@evil.com', role='admin

The query becomes: UPDATE users SET email='hacked@evil.com', role='admin' WHERE id=3

This sets both email AND role in one statement. The WHERE clause still applies, so only your own row changes.

UPDATE injection is particularly insidious because the change is quiet—no new rows appear, no data vanishes. The attacker's account simply gains elevated privileges. Without proper audit logging, this might never be detected. Always use parameterized queries and validate which columns can be modified.

LAB 03

Scorched Earth

The admin panel has a "Delete Product" feature that takes a product ID as input. Normally it removes a single row. But what if the attacker widens the WHERE clause to match every row?

DELETE FROM products WHERE id = [INPUT]
CHALLENGE

Delete ALL products from the table in a single request. Make the WHERE clause always true.

products table
IDNamePriceCategory

Use a tautology to make the WHERE clause match every row: 1 OR 1=1

The query becomes: DELETE FROM products WHERE id = 1 OR 1=1

Since 1=1 is always true, every single row matches the condition and gets deleted.

This is why DELETE without proper safeguards is catastrophic. A single tautology injection can empty entire tables. Unlike SELECT-based attacks that only read data, this attack causes permanent data loss. Production databases should always have backups, but more importantly, numeric parameters should still be validated and parameterized—never trust that "it's just a number."