GPT on Question 19, Oct 1

SQL injection occurs when untrusted input is interpreted as SQL syntax rather than as data. The classes overlap, but developers commonly group them as follows:

1. In-band SQL injection

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

• •Error-based: Database errors reveal schema, query, or configuration details.
• •UNION-based: A manipulated query combines attacker-selected data with the application’s normal result set.

2. Inferential (“blind”) SQL injection

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

• •Boolean-based: Different page content or status indicates whether a condition was true or false.
• •Time-based: Deliberate database delays reveal whether a condition was true.
• •Other observable differences—response size, redirects, or processing errors—can serve the same purpose.

3. Out-of-band SQL injection

The database is induced to communicate through another channel, such as DNS or an outbound network request. This depends on database features, privileges, and network access.

4. Stacked or piggybacked queries

Input terminates the intended statement and adds another statement. Whether this works depends heavily on the database driver and whether it permits multiple statements per call.

5. Second-order SQL injection

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

6. Dynamic-SQL injection inside database code

Stored procedures, functions, or administrative scripts construct SQL by concatenating parameters. Using a stored procedure is not automatically safe; its internal dynamic SQL must also be parameterized.

7. Injection in non-value query elements

Developers often parameterize values but overlook elements that usually cannot be bound as ordinary parameters:

• •Table or column names
• •Sort direction
• •ORDER BY expressions
• •Operators or SQL keywords
• •Dynamically constructed lists

These must come from strict allowlists or be mapped from user-facing choices to fixed SQL fragments.

Primary defenses

• 1.Use prepared statements and bound parameters everywhere.
• 2.Never build SQL by concatenating, interpolating, or formatting untrusted data.
• 3.For identifiers and query structure, use fixed mappings or allowlists—not escaping.
• 4.Apply least privilege: application accounts should not own schemas or have unnecessary write, administrative, file, or network permissions.
• 5.Avoid exposing detailed database errors to users; log them securely instead.
• 6.Review stored procedures, background jobs, reporting tools, and ORM “raw query” features.
• 7.Treat escaping as database-specific fallback protection, not the main defense.
• 8.Test with SAST/DAST and targeted security tests, including blind and second-order cases.

A concise rule for developers: SQL structure should be fixed by code; all external values should be passed separately as parameters.