SQL injection (SQLi)

The flaw in one picture

A web app often builds a database query using something the user typed, such as a username. If the app glues the input directly into the query text, a clever input can change what the query does. That is SQL injection (SQLi): the user's input is treated as part of the SQL code.

Imagine a login query built like this (the unsafe way):

query = "SELECT * FROM users WHERE name = '" + input + "'"
# If input is:  ' OR '1'='1
# the query becomes:
SELECT * FROM users WHERE name = '' OR '1'='1'
# '1'='1' is always true, so it may return every user and log the attacker in.

How a tester finds it (in a lab)

A tester puts a single quote or similar into a field and watches for a database error or a change in behaviour. In DVWA at the "low" level, this is the first thing you try. The point is not to steal data; it is to prove the input reaches the query unsafely, then write it up.

The fix: parameterised queries

The real fix is to never build query text from input. Instead, use parameterised queries (also called prepared statements): the query has placeholders, and the input is sent separately as data. The database then treats the input as a value, never as code, so no input can change the query's meaning.

// Unsafe:
db.query("SELECT * FROM users WHERE name = '" + name + "'");

// Safe: a placeholder, with the value passed separately
db.query('SELECT * FROM users WHERE name = ?', [name]);

Detection and defence

• Fix (primary): parameterised queries / prepared statements everywhere.
• Defence in depth: validate input types, give the database account least privilege, and never show raw database errors to users.
• Detection: database errors in logs, odd characters in inputs, and a web application firewall (WAF) flagging injection patterns.
• An ORM (a library that builds queries for you) uses parameters by default — but only if you avoid its raw-query escape hatches.