GPT on Question 18, Sep 25

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 sends input and receives results through the same application channel.

• •Error-based: Intentionally triggers database errors that reveal schema, query, or data details.
• •UNION-based: Alters a query so additional rows from another table are included in the normal response.
• •Tautology/authentication bypass: Changes a condition so it is always true, potentially bypassing login or filtering logic.

2. Inferential (“blind”) SQL injection

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

• •Boolean-based: Different application responses reveal whether a tested database condition is true or false.
• •Time-based: Conditional database delays reveal true/false results through response timing.

Blind SQLi can still extract substantial data, even when errors and query results are hidden.

3. Out-of-band SQL injection

The database is induced to communicate through a different channel, such as DNS or an outbound network request. This is less common and depends on database features, network access, and permissions.

4. Stacked-query injection

If the driver or database permits multiple statements in one call, injected input may terminate the intended statement and add another. Impact can extend beyond reading data to modifying records or executing administrative operations.

5. Second-order SQL injection

Malicious input is stored safely at first but later retrieved and concatenated into a new SQL statement. Validation only at the initial input boundary may therefore miss it.

Other useful distinctions

SQLi can occur in more than simple string or numeric values:

• •Dynamic table or column names
• •ORDER BY, sort direction, or pagination clauses
• •Search and filtering expressions
• •JSON/XML operators or database-specific syntax
• •Stored procedures containing dynamic SQL
• •ORM “raw query” or string-interpolation features

Primary defenses

• 1.Use parameterized queries/prepared statements for every data value.
• 2.Do not build SQL through string concatenation or interpolation.
• 3.For identifiers or keywords that cannot be parameterized—such as column names or sort direction—use a strict allowlist mapping.
• 4.Treat stored data as untrusted when it is reused in later queries, preventing second-order SQLi.
• 5.Run applications under least-privileged database accounts; separate read-only and write roles where practical.
• 6.Disable unnecessary database features, outbound connectivity, and multi-statement execution.
• 7.Return generic errors to users while retaining detailed server-side logs.
• 8.Test all query paths, including ORM escape hatches, report builders, background jobs, and administrative tools.

Escaping input and using a web application firewall can provide defense in depth, but neither should replace parameterization and safe query construction.