GPT on Question 18, Sep 13

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: Deliberately triggers database errors that may disclose schema details, query structure, or data.
• •UNION-based: Alters a query so data from another table or query is included in the application’s normal response.

2. Inferential (“blind”) SQL injection

The application does not directly return database output, but its behavior reveals whether a tested condition is true.

• •Boolean-based: The response changes—content, status code, result count, redirect, etc.—depending on whether a database condition is true or false.
• •Time-based: A database delay is conditionally triggered; response timing is used to infer information.

3. Out-of-band SQL injection

Data or signals leave through a different channel, such as a database-initiated DNS or network request. This depends on database features, permissions, and outbound network access.

4. Stacked-query injection

Input terminates the intended statement and adds another SQL statement. Whether this works depends on the database and driver’s support for multiple statements. Its impact can include data modification or administrative operations.

5. Second-order SQL injection

Malicious-looking input is initially stored safely, but later code retrieves it and concatenates it into a new SQL statement. The injection occurs during this later use, making it easy to miss in input-focused testing.

Useful secondary classifications

SQLi can also be categorized by where input is inserted:

• •String or numeric values
• •LIKE patterns
• •ORDER BY, column, table, or direction identifiers
• •List clauses such as IN (...)
• •Pagination parameters
• •Stored procedures or dynamic SQL
• •JSON/XML operators and database-specific query features

This distinction matters because parameterization protects values, but generally cannot parameterize identifiers or SQL keywords. Dynamic identifiers should be selected from strict allowlists.

Developer guidance

• 1.Use parameterized queries/prepared statements everywhere.
• 2.Do not build SQL through string concatenation or interpolation.
• 3.Allowlist dynamic identifiers and sort directions.
• 4.Avoid dynamic SQL inside stored procedures; parameterize it when unavoidable.
• 5.Use least-privileged database accounts and separate read/write or administrative roles.
• 6.Return generic errors to users while recording detailed errors securely.
• 7.Treat stored data as untrusted, which helps prevent second-order SQLi.
• 8.Test every query path, including APIs, background jobs, reporting tools, exports, and administrative interfaces.
• 9.Do not rely on escaping, input filtering, a WAF, or ORM use alone. ORMs are safe only when their parameterized APIs are used correctly.
• 10.Add regression tests and static-analysis rules that flag SQL construction involving untrusted data.