GPT on Question 19, Sep 28

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

1. In-band SQL injection

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

• •UNION-based: Alters a query so it returns data from unintended tables.
• •Error-based: Triggers database errors that reveal schema, query, or data details.
• •Stacked-query injection: Adds additional SQL statements where the database driver permits multiple statements.

2. Inferential (“blind”) SQL injection

The application does not directly display database results, but its behavior reveals whether injected conditions are true.

• •Boolean-based: The response changes—content, status code, redirect, or row count—depending on a database condition.
• •Time-based: Database delays are used to infer whether a condition is true.

“Blind” does not mean harmless; it may simply be slower to exploit.

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, privileges, and network access.

4. Second-order (“stored”) SQL injection

Malicious-looking input is stored safely at first, then later inserted unsafely into another SQL statement—for example, by an administrative report or background job. Validation only at initial entry does not prevent this.

5. Injection in non-value query elements

Parameterized queries protect data values, but applications often dynamically construct elements that generally cannot be bound as parameters, including:

• •Table or column names
• •Sort direction or ORDER BY fields
• •Operators
• •SQL fragments
• •Lists of expressions

These must be selected from strict allowlists, not copied from user input.

Root cause

Conceptually, the vulnerability looks like:

SQL text = "SELECT ... WHERE account = '" + userInput + "'"

The secure pattern keeps SQL structure fixed and binds the value separately:

SQL text = "SELECT ... WHERE account = ?"
bind userInput as a value

Developer guidance

• 1.Use prepared statements and parameter binding everywhere, including scripts, batch jobs, and stored procedures.
• 2.Never build queries by string concatenation or interpolation.
• 3.Allowlist dynamic identifiers and sort options.
• 4.Treat stored data as untrusted when it is reused, preventing second-order injection.
• 5.Use least-privilege database accounts; application accounts should not own schemas or have unnecessary administrative rights.
• 6.Avoid exposing detailed database errors to clients; log them securely instead.
• 7.Do not rely on escaping, input filtering, WAFs, or ORMs alone. ORMs are safe only when using their parameterized APIs rather than raw query construction.
• 8.Test all query paths, including search, login, reporting, exports, APIs, and background processes, with SAST/DAST and targeted code review.

The key message for developers is: separate SQL code from data at the database-driver boundary.