GPT on Question 19, Sep 19

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL command rather than strictly as data.

Main classes

1. In-band SQL injection

The attacker sends the payload and receives results through the same application channel.

• •UNION-based: Manipulates a query to append results from another query.
• •Error-based: Deliberately triggers database errors that reveal schema, query, or data details.

Verbose database errors make this easier, but hiding errors alone does not fix the vulnerability.

2. Inferential or “blind” SQL injection

The application does not directly display database results, so information is inferred from its behavior.

• •Boolean-based: The response changes depending on whether an injected condition is true or false.
• •Time-based: The attacker causes a conditional delay and infers the result from response timing.

Blind SQLi can remain exploitable even when responses are generic and no errors are shown.

3. Out-of-band SQL injection

The database is induced to send information through another channel, such as DNS or an outbound network request. This depends on database features, privileges, and network access.

4. Stacked-query injection

If the database driver permits multiple statements in one call, injected input can terminate the intended statement and add another. Potential effects include modifying data, creating accounts, or invoking dangerous database functionality.

5. Second-order SQL injection

Malicious input is stored safely at first but later retrieved and concatenated into a SQL statement. Validation at initial entry does not prevent this; every query construction point must use parameters.

6. Injection in non-value query elements

Parameters generally protect values, not SQL structure. Vulnerabilities can occur when user input controls:

• •Table or column names
• •Sort columns or ASC/DESC
• •Operators
• •SQL fragments
• •Pagination syntax
• •Dynamic filters

These inputs require strict allowlists and application-side mapping, not escaping.

7. SQL injection inside stored procedures or ORM usage

Stored procedures and ORMs are not automatically safe. They remain vulnerable when they build dynamic SQL by concatenating input or expose “raw query” interfaces.

Common root cause

The typical unsafe pattern is constructing SQL text with string concatenation, interpolation, or formatting:

query = "SELECT ... WHERE email = '" + userInput + "'"

The safe pattern keeps SQL code and data separate:

query = "SELECT ... WHERE email = ?"
execute(query, [userInput])

Exact placeholder syntax varies by driver.

Developer guidance

• 1.Use prepared statements and bound parameters everywhere, including background jobs and administrative tools.
• 2.Never build SQL by concatenating input.
• 3.Allowlist dynamic identifiers and keywords, mapping external choices to hard-coded SQL fragments.
• 4.Avoid dynamic SQL in stored procedures; parameterize it when unavoidable.
• 5.Use least-privileged database accounts and separate read-only from write-capable roles.
• 6.Disable unnecessary database features and outbound network access.
• 7.Return generic errors to clients while securely logging detailed errors server-side.
• 8.Treat escaping as a last resort, not the primary defense; it is database-, encoding-, and context-dependent.
• 9.Test all data flows, including stored values, JSON fields, headers, batch operations, and ORM raw-query paths.
• 10.Add automated security testing and code-review rules that flag SQL concatenation.

The key briefing message is: SQL injection is prevented by separating SQL structure from untrusted data—not by trying to detect malicious-looking input.