GPT on Question 19, Sep 15

SQL injection occurs when untrusted input is interpreted as part of SQL syntax rather than strictly as data. The major classes overlap: one describes how the injected SQL executes, another how results are retrieved, and another when injection occurs.

Main classes

1. In-band SQL injection

The attacker sends the injection and receives results through the same application response.

• •UNION-based: Manipulates a query so it combines legitimate results with data from other tables.
• •Error-based: Deliberately triggers database errors that reveal schema details or data through error messages.

Defense: Parameterized queries and generic production error messages; never expose raw database errors.

2. Blind or inferential SQL injection

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

• •Boolean-based: Differences in page content, status codes, or other behavior reveal query outcomes.
• •Time-based: Conditional database delays reveal outcomes through response timing.

Defense: Parameterization remains the primary control. Uniform responses and timeouts may reduce the signal, but they do not fix the vulnerability.

3. Out-of-band SQL injection

The attacker causes the database to send information over another channel, such as a network or DNS request. This depends on database features, permissions, and outbound connectivity.

Defense: Use least-privilege database accounts, disable unnecessary database networking or file features, and restrict outbound traffic from database servers.

4. Stacked-query injection

If the database driver permits multiple statements in one call, injected input may terminate the intended statement and add another operation, such as modifying data.

Defense: Use parameterized APIs, disable multi-statement execution where possible, and restrict write and administrative permissions.

5. Second-order or stored SQL injection

Malicious text is stored safely at first but later retrieved and concatenated into a new SQL statement. Validation at initial entry does not prevent unsafe use later.

Defense: Treat all data as untrusted whenever constructing a query—even data already stored in your own database.

6. Injection into non-value SQL elements

Bind parameters usually protect values, but many APIs cannot parameterize structural elements such as:

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

Defense: Map user choices to a strict server-side allowlist. Never place arbitrary user text into SQL structure.

Common injection contexts

Injection can occur in:

• •String, numeric, date, or binary values
• •Search and filtering expressions
• •Dynamic SQL inside stored procedures
• •ORM “raw query” or string interpolation features
• •Reporting tools and query builders
• •HTTP headers, cookies, filenames, message queues, or imported files—not only form fields

Core developer guidance

• 1.Use prepared statements with bound parameters everywhere.
• 2.Do not build SQL using concatenation, interpolation, or formatting.
• 3.Allowlist dynamic identifiers and sort/filter options.
• 4.Avoid dynamic SQL in stored procedures; parameterize it when unavoidable.
• 5.Give application database accounts only required permissions.
• 6.Suppress detailed database errors in production and log them securely.
• 7.Do not rely on escaping, input validation, a WAF, or an ORM alone.
• 8.Test with SAST, DAST, code review, and integration tests targeting every query path.

A useful review rule is: every variable part of a query must be either a bound value or selected from a fixed allowlist.