GPT on Question 19, Sep 29

SQL injection occurs when untrusted input is interpreted as part of a SQL statement 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 errors reveal schema, query structure, or data.
• •UNION-based: An attacker modifies a query so additional database results appear in the normal response.

2. Inferential (“blind”) SQL injection

The application does not directly return database data, so the attacker infers it 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 side channels can include response size, redirects, or processing differences.

3. Out-of-band SQL injection

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

4. Stacked-query injection

If the driver/database permits multiple statements in one call, injected input can append another statement. This can enable data modification or administrative actions, not just data disclosure.

5. Second-order SQL injection

Malicious input is stored safely at first but later inserted unsafely into another SQL statement—for example, when a background job or admin report processes stored profile data.

6. Injection into non-value query elements

Parameters usually protect values, but applications often build other SQL elements dynamically:

• •Table or column names
• •Sort direction or ORDER BY fields
• •Operators or SQL keywords
• •Query fragments such as filters

These elements generally require strict allowlists or fixed query templates, not ordinary value parameters.

Key guidance for developers

• 1.Use parameterized queries/prepared statements everywhere.
• 2.Never build SQL by concatenating or formatting untrusted input.
• 3.For dynamic identifiers or sort options, map user choices to an allowlist of known-safe constants.
• 4.Treat stored procedures and ORMs as safe only when they avoid dynamic SQL and raw-query concatenation.
• 5.Use a least-privileged database account; separate read, write, and administrative roles where practical.
• 6.Disable unnecessary database features and outbound network access.
• 7.Return generic errors to users while logging detailed errors securely.
• 8.Test all input paths, including headers, cookies, JSON fields, bulk imports, and previously stored data.
• 9.Use SAST/DAST and dependency scanning, but do not treat a WAF as a replacement for parameterization.

A useful briefing summary is: SQL injection is not primarily an input-validation problem; it is a failure to keep code and data structurally separate.