SQL Injection, End to End

SQL injection (SQLi) happens when user input is mixed directly into a database query, letting an attacker rewrite what that query does. The database cannot tell the difference between the logic the developer wrote and the logic the attacker smuggled in through an input field.

How it works

Consider a login query built by string concatenation:

-- The developer's intent
SELECT * FROM users WHERE email = '$email' AND password = '$password';

If the attacker submits ' OR '1'='1 as the email, the query the database actually runs becomes:

SELECT * FROM users WHERE email = '' OR '1'='1' AND password = '';

'1'='1' is always true, so the WHERE clause matches every row and the attacker logs in as the first user - often an administrator - without knowing any password. The single quote broke out of the string context; everything after it was interpreted as SQL.

Types of SQLi

• In-band (classic): results come back in the response. Union-based injection appends a UNION SELECT to pull data from other tables; error-based coaxes the database into leaking data inside error messages.
• Blind: no data or errors are returned, but the app behaves differently based on a true/false condition. Boolean-based asks yes/no questions one bit at a time; time-based uses SLEEP() to read answers from response delays.
• Out-of-band: the database is made to send data to an attacker-controlled server (e.g. via DNS), used when the channel is otherwise silent.

A worked example

An article page loads with /article?id=5 and runs SELECT title, body FROM articles WHERE id = 5. The id is attacker-controlled and unparameterised, so a union payload can graft in sensitive data:

/article?id=0 UNION SELECT username, password_hash FROM users -- 

The page dutifully renders usernames and password hashes where the article title and body should be. From there it is offline cracking and account takeover.

Real-world impact

• Confidentiality: dump entire tables - customers, credentials, payment data.
• Integrity: modify or delete records, forge transactions, plant backdoor accounts.
• Authentication bypass: log in as anyone, as shown above.
• Escalation to the host: features like xp_cmdshell or writing files can turn a database bug into operating-system command execution.

How to prevent it

There is one primary fix, and it is airtight: parameterized queries (prepared statements). Send the query structure and the data separately so the input can never be parsed as SQL.

// Vulnerable: string concatenation
db.query("SELECT * FROM users WHERE email = '" + email + "'");

// Safe: parameterized - the driver binds `email` as pure data
db.query("SELECT * FROM users WHERE email = ?", [email]);

Layer defence in depth on top:

• Use an ORM / query builder that parameterizes by default - but stay alert to raw-query escape hatches.
• Least privilege: the app's database account should not be able to drop tables or read system schemas.
• Input validation as a secondary control (allowlist expected formats), never as the primary one.
• A WAF buys time against known payloads but is bypassable - it is not a substitute for parameterization.