SQL injection is a web application vulnerability that allows an attacker to manipulate a database query by inserting their own SQL syntax into input that the application sends to the database. The flaw arises when user-supplied input is concatenated directly into a query rather than being passed as a parameter, allowing the input to break out of its intended context and run attacker-chosen SQL.
A simple example
Consider an application that builds a login query as:
SELECT * FROM users WHERE username = '$user' AND password = '$pass'If $user is “admin’ OR ‘1’=’1” and $pass is anything at all, the resulting query becomes:
SELECT * FROM users WHERE username = 'admin' OR '1'='1' AND password = 'anything'The “OR ‘1’=’1′” clause is always true, so the WHERE filter matches every row. The application returns valid users and treats the attacker as authenticated.
Variants
In-band SQL injection returns the results of the attacker’s query in the application response. The simplest variant for an attacker to confirm.
Blind SQL injection occurs when the application processes the injected query but does not return the result. The attacker infers data by asking yes/no questions (boolean-based) or by timing how long the database takes to respond (time-based).
Out-of-band injection uses a side channel (DNS lookups, HTTP requests from the database server) to exfiltrate data when no other channel is available.
Impact
At minimum, SQL injection allows the attacker to read data they should not see. In many cases it permits writing or deleting data, escalating privileges within the application, dumping the entire database, executing operating-system commands through database extensions, or pivoting deeper into the network. Several of the highest-profile UK data breaches of the past decade originated in SQL injection on public-facing applications.
Defences
The right defence is parameterised queries (also called prepared statements). The query template and the user data are sent to the database separately, so user input is never interpreted as SQL syntax. Object-relational mappers (ORMs) such as Entity Framework, Hibernate, and Django ORM use parameterised queries by default. Stored procedures help only when implemented with parameters; concatenating input inside a stored procedure recreates the same flaw. Input validation and web application firewalls add useful defence in depth but should not be the primary control.
Related terms
See also: sqlmap, Burp Suite, web application penetration testing, and cross-site scripting.
Leave a Reply