GPT on Question 19, Sep 18

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL command rather than as data. The major classes are:

1. In-band SQL injection

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

• •Error-based: Database error messages reveal schema, query structure, or data.
• •UNION-based: A manipulated query combines attacker-selected results with the application’s normal result set.

Risk: Direct disclosure or modification of database data.

2. Inferential (“blind”) SQL injection

The application does not directly return database results, so the attacker infers information from behavior.

• •Boolean-based: The response differs depending on whether an injected condition is true or false.
• •Time-based: Conditional database delays reveal true/false outcomes through response timing.

Risk: Data can still be extracted gradually even when errors and query results are hidden.

3. Out-of-band SQL injection

The database is induced to communicate through a separate channel, such as DNS or an outbound network request.

Risk: Data exfiltration where ordinary application responses reveal nothing. This generally depends on database features and outbound network access.

4. Stacked or piggybacked queries

Input causes an additional SQL statement to run after the intended one. Whether this works depends on the database driver and configuration.

Risk: Data changes, account creation, privilege changes, or destructive operations.

5. Second-order SQL injection

Malicious input is stored safely at first but later inserted unsafely into another SQL statement—for example, by an administrative report or background job.

Risk: Vulnerabilities may trigger far from the original input point and evade routine testing.

Injection can occur in multiple SQL contexts

Developers should not focus only on quoted string fields. Unsafe construction can affect:

• •Numeric values
• •WHERE clauses
• •Sorting and column names
• •Table names
• •LIMIT/pagination values
• •Stored procedures and dynamic SQL
• •JSON/XML operators or full-text queries exposed through SQL
• •Administrative scripts and reporting tools

Primary defenses

• 1.Use parameterized queries/prepared statements for every data value.
• 2.Never build SQL by concatenating input.
• 3.For identifiers that usually cannot be parameterized—such as sort columns or table names—use a strict allowlist mapping, not escaping.
• 4.Use ORM/query-builder APIs correctly; raw-query features can still be vulnerable.
• 5.Run the application database account with least privilege.
• 6.Avoid exposing database errors to users; log them securely instead.
• 7.Disable unnecessary database features, stacked statements, and outbound network access.
• 8.Test all input paths, including stored data and asynchronous jobs, with SAST/DAST and focused security review.

A useful rule for developers is: parameterization controls query structure; validation controls what the application considers acceptable. Both are needed, but validation alone does not prevent SQL injection.