SQL injection: when input becomes part of the query

Definitions follow OWASP and CWE-89.

An application builds a query by joining strings: the fixed part written by the developer, and a value taken from the request, such as an account number or a search term. If the value is joined in as text, the database cannot tell where the developer's query ends and the user's input begins.

An attacker sends input that contains SQL syntax: a quote that closes the string, an operator that changes the condition, or a clause that adds a second query. The database runs the result as one command. OWASP's standard example turns a lookup for one account into a lookup that returns every account by adding a condition that is always true.

• In-band SQL injection. Results come back in the application's own response, either as data (union-based) or in database error messages (error-based).
• Blind SQL injection. Nothing is shown; the attacker infers answers from whether a page changes (boolean-based) or how long it takes to respond (time-based).
• Out-of-band SQL injection. The database is made to send data through another channel, such as a DNS or HTTP request to a server the attacker controls.
• Second-order SQL injection. Input is stored safely first and only becomes part of a query later, in a different feature that trusts stored data.

The types differ in how data leaves, not in the cause: in every case input was joined into a query as text.

Most SQL injection attempts carry characters that have no business in the field: quotes in a numeric identifier, comment markers, keywords such as UNION or SELECT in a search box, or operators that build a condition. Automated scanners send many of these in a short time, which also shows in the request rate.

Legitimate text can contain the same characters. A support ticket quoting a query or a name with an apostrophe looks similar to a filter, which is why rules for SQL injection are scored and tuned per site.

A request filter matches the shapes above and can refuse them before they reach the code; rule sets such as the OWASP Core Rule Set keep a dedicated group of rules for it. That protects an injectable query while it is being fixed.

It misses what does not look like SQL in the request: second-order injection, input encoded in a way the rules do not decode, and injection through channels the filter does not read. And it leaves the query vulnerable, so the next variation may get through.

1. Use parameterised queries. Prepared statements send the query and the values separately, so input can never become syntax. The OWASP SQL Injection Prevention Cheat Sheet puts this first.
2. Use stored procedures carefully. They help only if they do not build SQL from strings inside.
3. Validate input against what is allowed. An allow-list for things that cannot be parameters, such as column names or sort order.
4. Give the database account the least privilege it needs. So an injection that slips through can read less and change nothing it should not.
5. Do not show database errors to users. Error text helps attackers map the query.