GPT on Question 18, Sep 15

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

1. In-band SQL injection

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

• •Error-based SQLi: Intentionally triggers database errors that reveal schema, query, or data details.
• •UNION-based SQLi: Alters a query so results from another table or expression are included in the application’s normal response.

These are often easiest to detect because the response visibly changes or leaks database errors.

2. Inferential or “blind” SQL injection

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

• •Boolean-based: The tester submits conditions that evaluate true or false and observes differences in content, status codes, redirects, or response sizes.
• •Time-based: The condition causes a database-side delay, allowing its truth value to be inferred from response timing.

Blind SQLi can exist even when the application always displays a generic message.

3. Out-of-band SQL injection

The database is induced to communicate through a different channel, such as a DNS or HTTP request. This is relevant when application responses do not expose useful differences, but it requires database features and outbound network access.

4. Stacked-query injection

Input terminates or extends the intended statement and adds another SQL statement. Whether this works depends on the database, driver, and configuration. Its impact can extend beyond data disclosure to modifying records or administrative actions.

5. Second-order SQL injection

Malicious-looking data is stored safely at first but later incorporated unsafely into another query. For example, a value written through a parameterized insert might later be concatenated into an administrative report query. Testing only the initial request can miss this class.

6. Injection in non-value query elements

Parameters are commonly used for values, but developers sometimes concatenate input into SQL syntax such as:

• •Column or table names
• •Sort direction and ORDER BY clauses
• •Search operators
• •Pagination clauses
• •Dynamically constructed filters

These elements usually cannot be parameterized conventionally and should instead be selected from strict allowlists.

7. Injection through database-adjacent abstractions

SQLi can arise in stored procedures, query builders, ORMs, and reporting tools when they use raw SQL or dynamic string construction. An ORM reduces risk but does not eliminate it. Similar injection patterns can affect non-relational query languages as well.

Primary defenses

• 1.Use prepared statements and parameterized queries everywhere.
• 2.Avoid constructing SQL with string concatenation or interpolation.
• 3.Allowlist dynamic identifiers and keywords.
• 4.Treat stored data as untrusted when it is reused.
• 5.Give application database accounts least privilege.
• 6.Suppress detailed database errors in client responses while retaining them in protected logs.
• 7.Use code review and static analysis to find raw/dynamic SQL.
• 8.Test every input location, including JSON fields, headers, cookies, route parameters, background jobs, imports, and administrative interfaces.
• 9.Do not rely on escaping, input filtering, or a WAF as the primary control.

A useful developer rule is: SQL structure must be fixed by code; externally influenced values must be bound as parameters, and externally influenced structure must come from an explicit allowlist.