How SQL injection works
Web applications typically build database queries by concatenating user-supplied input with SQL code. For example, a login form might construct a query like this:
SELECT * FROM users WHERE username = 'input' AND password = 'input'If an attacker enters
' OR '1'='1 as the username, the query becomes:SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'Since
'1'='1' is always true, this returns all user records — bypassing authentication entirely.
The root cause is trusting user input. When user-supplied data is inserted directly into a SQL query without sanitisation or parameterisation, the database cannot distinguish between SQL code intended by the developer and SQL code injected by an attacker.
Types of SQL injection
-
1In-band SQLi (Classic) — The attacker injects SQL and the results are returned directly in the web page response. Includes error-based SQLi (exploiting verbose error messages) and UNION-based SQLi (appending a UNION SELECT to extract data from other tables).
-
2Blind SQLi — No data is returned in the response. The attacker asks true/false questions by observing the application's behaviour. In boolean-based blind SQLi, different content loads depending on whether the condition is true or false. In time-based blind SQLi, the attacker uses SQL commands like
SLEEP(5)to cause delays that confirm query execution. -
3Out-of-band SQLi — Data is exfiltrated through a different channel — for example, using SQL functions that make DNS lookups or HTTP requests to an attacker-controlled server. Useful when in-band and blind techniques are too slow or unreliable.
What attackers can achieve with SQLi
SQL injection is not just about reading data. Depending on the database, application, and permissions, a successful SQLi attack can enable:
- Authentication bypass: Log in as any user, including admins, without a valid password.
- Data exfiltration: Dump entire database tables — usernames, passwords, payment card numbers, personal data.
- Data manipulation: Modify or delete records. An attacker could alter financial records, change user roles, or wipe a database entirely.
- OS command execution: On databases with features like xp_cmdshell (MS SQL Server) or INTO OUTFILE (MySQL with file write privileges), SQLi can lead to remote code execution on the database server.
How to prevent SQL injection
SQL injection is almost entirely preventable with proper coding practices:
- Parameterised queries (prepared statements): The most effective defence. User input is passed as a parameter — not concatenated into the SQL string — so it can never alter the query structure. Available in every major language and database framework.
- Stored procedures: Pre-compiled SQL queries that accept parameters safely. When implemented correctly, equivalent to parameterised queries in protection.
- Input validation: Reject or sanitise input that contains SQL special characters. Not a primary defence (it can be bypassed) but adds a useful layer.
- Least-privilege database accounts: The database account used by the web application should only have SELECT access to the tables it needs — limiting what an attacker can do even if they achieve injection.
- Web Application Firewall (WAF): Can detect and block common SQLi patterns in HTTP requests, adding a layer of protection even against unknown vulnerabilities.
CEH v13 includes hands-on DVWA and Juice Shop exercises where you perform real SQL injection attacks in a safe, legal environment.