GPT on Question 18, Oct 2

SQL injection (SQLi) occurs when untrusted input changes the structure or meaning of a database query instead of being treated strictly as data.

Main classes

1. In-band SQL injection

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

• •Error-based SQLi: Deliberately triggers database errors that reveal schema details, query structure, DBMS type, or data.
• •UNION-based SQLi: Manipulates a query to append results from another compatible query, potentially exposing data from other tables.

2. Inferential (“blind”) SQL injection

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

• •Boolean-based blind SQLi: Injected conditions cause distinguishable responses—for example, different page content, status codes, or record counts depending on whether a condition is true.
• •Time-based blind SQLi: Database operations conditionally delay the response. Response timing is used to infer whether a condition is true.

Blind SQLi may be slower but can still disclose data one bit or character at a time.

3. Out-of-band SQL injection

Data is returned through a separate channel rather than the application response, such as a database-triggered DNS or network request. This requires specific DBMS capabilities and outbound connectivity.

Other important categories

• •Stacked-query injection: The driver or DBMS accepts multiple statements in one request, allowing an additional statement to run after the intended query.
• •Second-order SQLi: Malicious input is stored safely at first but later concatenated into another query and executed. Validate query construction at every use, not just at initial input.
• •Stored-procedure/dynamic-SQL injection: A procedure may still be vulnerable if it builds SQL by concatenating parameters.
• •Identifier or structural injection: User input controls table names, column names, sort direction, or SQL fragments. These often cannot be handled with ordinary value placeholders and require strict allowlists.

Root cause

The usual cause is constructing SQL by string concatenation or interpolation, for example combining a query template with user-supplied values. Escaping alone is fragile because rules vary by DBMS, encoding, driver, and SQL context.

Primary defenses

• 1.Use parameterized queries/prepared statements for every data value.
• 2.Allowlist structural choices such as column names, table names, and sort order; map user-facing options to hard-coded SQL identifiers.
• 3.Avoid dynamic SQL where possible. If unavoidable, parameterize values and quote identifiers using DBMS-supported APIs.
• 4.Apply least privilege: Separate application accounts by role; deny unnecessary write, schema, filesystem, and network permissions.
• 5.Suppress detailed database errors from client responses while retaining them in protected logs.
• 6.Review stored procedures, ORMs, and query builders: They are safe only when used without raw string interpolation.
• 7.Test all input locations: URL parameters, JSON fields, headers, cookies, stored data, search/filter APIs, and batch/import features.
• 8.Use SAST/DAST and dependency scanning, but treat scanners and WAFs as supplementary rather than primary defenses.

A useful review rule for developers is: every SQL value must be bound as a parameter, and every SQL identifier or keyword influenced by a user must come from a small explicit allowlist.