GPT on Question 18, Sep 26

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL command rather than strictly as data. Developers should understand both how results are obtained and where injection can occur.

Main classes by exploitation technique

• 1.In-band SQLi
  The attacker sends input and receives results through the same application response.
• •Error-based: Database errors reveal query structure, schema details, or data.
• •UNION-based: A manipulated query combines attacker-selected results with the application’s normal result set.

• 2.Inferential (“blind”) SQLi
  The application does not directly return database output, so information is inferred from behavior.
• •Boolean-based: Responses differ depending on whether an injected condition is true or false.
• •Time-based: Deliberate database delays indicate whether a condition evaluated as expected. This can exist even when pages and status codes appear identical.

• 3.Out-of-band SQLi
  Data or confirmation is delivered through a separate channel, such as a database-triggered DNS or network request. This depends on database features, privileges, and outbound connectivity.

• 4.Stacked or piggybacked queries
  If the driver permits multiple statements in one call, injected input may cause an additional SQL statement to execute. Impact can extend beyond reading data to modification or administrative actions.

• 5.Second-order SQLi
  Malicious-looking input is stored safely at first, but is later concatenated into another dynamic query and executed. Validation only at initial entry does not prevent this.

Common injection contexts

SQLi is not limited to quoted string values. It can occur in:

• •Numeric values
• •Search filters
• •ORDER BY, column, table, or direction selections
• •LIMIT/pagination expressions
• •Dynamic table or schema names
• •Stored procedures that construct dynamic SQL
• •ORM “raw query” or string-expression APIs
• •JSON/XML-to-SQL translation layers
• •Administrative, reporting, import, and background-job code

Key developer guidance

• •Use parameterized queries/prepared statements for every data value.
• •Do not build SQL through string concatenation, interpolation, or formatting.
• •For identifiers that usually cannot be parameterized—such as column names or sort directions—use a strict allowlist mapping from user choices to hard-coded SQL fragments.
• •Avoid dynamic SQL in stored procedures; if unavoidable, parameterize it internally.
• •Use a minimally privileged database account and separate read/write or administrative roles.
• •Disable multi-statement execution unless explicitly required.
• •Return generic errors to users while retaining detailed errors in protected logs.
• •Treat escaping as database-specific defense-in-depth, not a substitute for parameters.
• •Test delayed and second-order execution paths, including stored data, reports, exports, and background workers.
• •Add SAST/DAST and code-review checks for query construction, but do not rely on a WAF as the primary fix.

A useful summary for developers is: parameters protect data values; allowlists protect SQL structure; least privilege limits impact.