GPT on Question 19, Sep 24

SQL injection occurs when untrusted input is interpreted as part of a SQL command rather than strictly as data. The main classes are:

1. In-band SQL injection

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

• •UNION-based: Combines attacker-selected data with the application’s legitimate query results.
• •Error-based: Provokes database errors that reveal schema details, query structure, or data.

2. Inferential (“blind”) SQL injection

The application does not directly return database output, so information is inferred from behavior.

• •Boolean-based: Responses differ depending on whether an injected condition evaluates true or false.
• •Time-based: Deliberate database delays indicate whether a condition was true.

3. Out-of-band SQL injection

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

4. Stacked-query injection

Input terminates the intended statement and adds one or more additional statements. Whether this works depends on the database, driver, and configuration. Potential impact includes data modification or administrative operations.

5. Second-order SQL injection

Malicious input is stored safely at first, but later retrieved and concatenated into another SQL statement. Validation at initial entry alone therefore does not solve the problem.

6. Injection in non-value query elements

Parameters are not always values. Dynamic table names, column names, sort directions, operators, and SQL fragments can also be injection points. Bind parameters usually cannot represent these elements, so use strict allowlists or fixed query mappings.

Developer guidance

• •Use parameterized queries/prepared statements everywhere, including background jobs and stored-data workflows.
• •Avoid constructing SQL with string concatenation, interpolation, or templating.
• •For identifiers or sort options, map user choices to a small allowlist of predefined SQL fragments.
• •Treat stored procedures as safe only if they do not build dynamic SQL unsafely.
• •Use least-privileged database accounts; separate read-only and write roles where practical.
• •Suppress detailed database errors in user-facing responses, while retaining secure server-side logs.
• •Do not rely on escaping, input filtering, a WAF, or client-side validation as the primary defense.
• •Test with SAST/DAST, dependency scanning, code review, and targeted security tests covering blind and second-order cases.

A useful review rule is: Any place where untrusted data can alter SQL syntax or structure is a potential SQL injection vulnerability.