GPT on Question 18, Sep 27

SQL injection occurs when untrusted input is interpreted as part of a SQL statement rather than strictly as data. The major classes overlap; they describe either how injection happens or how an attacker obtains results.

Main classes

1. In-band SQL injection

The injection and returned results use the normal application response.

• •Error-based: Deliberately triggers database errors that may reveal query structure, schema details, or data.
• •UNION-based: Alters a query so results from an additional attacker-controlled query are included in the application’s normal output.

Common signs: Database errors in responses, unexpected columns or rows, and unusual query syntax in request parameters.

2. Inferential or “blind” SQL injection

The application does not directly display query results, but its behavior reveals whether a condition was true.

• •Boolean-based: The attacker compares changes in status codes, page content, row counts, redirects, or other behavior.
• •Time-based: The attacker causes conditional database delays and infers results from response timing.

Blind injection can still disclose substantial data, although it typically requires many requests.

3. Out-of-band SQL injection

The database is induced to communicate through a different channel, such as DNS or an outbound network request. This depends on the database engine, enabled features, privileges, and network egress.

Mitigation implication: Databases generally should not have unrestricted outbound connectivity.

4. Stacked-query or piggybacked injection

If the driver and database permit multiple statements in one call, injected input may append a separate SQL statement. The impact can extend beyond reading data to modifying records or database configuration, depending on privileges.

Disabling multi-statement execution helps, but is not a substitute for parameterization.

5. Second-order SQL injection

Malicious input is safely stored at first but later retrieved and concatenated into another SQL statement. Validation at initial entry may therefore miss the vulnerable execution point.

Treat data retrieved from your own database as untrusted whenever it is used to construct another query.

6. Injection into non-value query elements

Bind parameters generally protect values, but many APIs cannot bind structural elements such as:

• •Table or column names
• •Sort direction
• •ORDER BY fields
• •Operators
• •SQL keywords or fragments

These must be selected from strict server-side allowlists rather than copied from request input.

7. Dynamic SQL in stored procedures

Stored procedures are not inherently safe. They are vulnerable when they build SQL strings through concatenation or execute user-controlled dynamic SQL. Procedures using fixed statements and bound parameters can be safe.

Common root causes

• •String concatenation or interpolation when building queries
• •Misuse of ORM “raw query” features
• •Incorrect assumptions that escaping is universally safe
• •Character-set or type-conversion inconsistencies
• •Dynamic query construction for filters, sorting, or reporting
• •Excessive database privileges
• •Detailed database errors exposed to users

Developer guidance

• 1.Use prepared statements and bound parameters everywhere.
• 2.Allowlist structural choices such as sort columns and directions.
• 3.Avoid dynamic SQL; where unavoidable, isolate and review it carefully.
• 4.Use least-privileged database accounts, separating read-only and write roles where practical.
• 5.Suppress detailed SQL errors externally while retaining them in protected logs.
• 6.Restrict database network egress and disable unnecessary database features.
• 7.Treat stored data as untrusted at every later SQL execution point.
• 8.Review ORM escape hatches, stored procedures, report builders, and search/filter endpoints.
• 9.Test both immediate and blind behavior, including response differences and timing anomalies.
• 10.Prefer remediation over filtering: WAF rules and input validation are defense-in-depth, not replacements for parameterized queries.

A concise message for developers is: Never construct SQL by joining code and data. Bind values, allowlist query structure, and run the database with minimal privileges.