GPT on Question 19, Sep 20

SQL injection (SQLi) occurs when untrusted input changes the intended structure of a database query. The main classes are:

1. In-band SQL injection

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

• •Error-based: Database error messages reveal schema, query, or data details.
• •Union/query-based: An injected query causes additional data to be included in the normal response.

2. Inferential or “blind” SQL injection

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

• •Boolean-based: Responses differ depending on whether an injected condition is true or false.
• •Time-based: Deliberate database delays are used to infer whether a condition is true.

3. Out-of-band SQL injection

Data is retrieved through a separate channel—such as a database-triggered DNS or network request—when direct responses are unavailable. This depends on database network access and specific features.

4. Stacked or piggybacked queries

Input terminates the intended statement and adds another SQL statement. Impact can include data modification or administrative operations. Support varies by database driver and configuration.

5. Second-order SQL injection

Malicious input is stored safely at first, but later reused unsafely when constructing another query. Validation only at initial entry does not prevent this; every database operation must use parameters.

6. Injection by SQL context

SQLi can also be classified by where unsafe input is inserted:

• •String or numeric values
• •LIKE patterns
• •IN lists
• •Identifiers such as table or column names
• •Sorting and direction clauses
• •Pagination values
• •Dynamic query fragments or stored procedures

Parameterized queries protect values, but usually not identifiers or SQL keywords. Dynamic identifiers and sort options should be selected from strict allowlists.

Key guidance for developers

• 1.Use prepared statements and parameterized queries everywhere.
• 2.Never construct SQL by concatenating or interpolating user-controlled values.
• 3.Allowlist any dynamic table names, columns, sort directions, or operators.
• 4.Treat stored procedures and ORM “raw query” APIs as potentially injectable.
• 5.Apply least-privilege database accounts; separate read and write roles where practical.
• 6.Suppress detailed database errors in user-facing responses, while retaining secure server-side logs.
• 7.Validate input as defense in depth—not as a substitute for parameterization.
• 8.Test both immediate and stored-input/second-order paths using code review, SAST, DAST, and authorized security testing.
• 9.Restrict unnecessary database network access and hazardous database features.
• 10.Remember that escaping is database- and context-specific; prefer binding parameters rather than relying on manual escaping.