GPT on Question 18, Sep 28

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL command rather than as data. The most useful way to brief developers is by how injection is exploited and where it enters the query.

Main classes

1. In-band SQL injection

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

• •UNION-based: Manipulates a query so data from another table or query appears in the normal response.
• •Error-based: Deliberately triggers database errors that reveal schema details, query structure, or data.

These are most visible when applications return query results or detailed database errors.

2. Inferential or “blind” SQL injection

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

• •Boolean-based: The attacker submits conditions expected to be true or false and observes differences in content, status codes, redirects, or record counts.
• •Time-based: The attacker causes conditional database delays and infers results from response timing.

“Blind” does not mean harmless; it may simply be slower and harder to detect.

3. Out-of-band SQL injection

The injected query causes the database to communicate through another channel, such as DNS or an outbound network request. This depends on database features, privileges, and network egress. It is especially relevant when application responses reveal nothing but the database server can initiate external connections.

4. Stacked or piggybacked queries

Input terminates the intended statement and adds another statement. Whether this works depends on the database, driver, and configuration. Potential effects can include modifying data or database configuration, not merely reading it.

5. Second-order SQL injection

Malicious input is stored safely at first, then later retrieved and concatenated into a different SQL statement. Validation at the original entry point may therefore miss the actual execution point.

Example pattern:

• 1.A crafted account attribute is stored in the database.
• 2.A later reporting or administrative process reads it.
• 3.That process builds SQL through string concatenation.
• 4.The stored value becomes executable SQL syntax.

6. Injection into non-value query elements

Parameters generally protect values, but many applications dynamically construct other SQL elements, including:

• •Table or column names
• •Sort direction
• •ORDER BY fields
• •Operators
• •Filter fragments
• •Pagination clauses

These elements often cannot be bound as ordinary parameters. They should be selected from strict server-side allowlists rather than copied from request input.

Common root causes

• •String concatenation or interpolation when building SQL
• •“Escaping” input instead of using parameter binding
• •Dynamic SQL inside stored procedures
• •ORM escape hatches that accept raw query fragments
• •Reusing stored data in later dynamic queries
• •Overprivileged database accounts
• •Detailed database errors exposed to users

Primary defenses

• 1.Use prepared statements and bound parameters everywhere.
  Parameterization, not input filtering, is the main defense.

• 2.Allowlist dynamic identifiers and query structure.
  Map user choices such as "name" or "date" to hard-coded SQL identifiers.

• 3.Avoid raw SQL APIs where practical.
  ORMs help only when their parameterized interfaces are used correctly.

• 4.Review stored procedures for dynamic SQL.
  Stored procedures are not automatically safe.

• 5.Apply least privilege.
  The application account should have only the required permissions and ideally no schema-administration privileges.

• 6.Return generic errors externally and log details internally.

• 7.Treat stored data as untrusted.
  Parameterize queries even when values came from your own database.

• 8.Use testing and review as secondary controls.
  Add SAST, DAST, dependency scanning, query logging, and targeted tests, but do not treat a WAF as the primary fix.

Developer review checklist

Look for:

• •SQL strings containing request variables or string interpolation
• •ORM methods named like raw, execute, literal, or extra
• •Dynamic ORDER BY, table names, or column names
• •SQL assembled in stored procedures
• •Database errors in HTTP responses
• •Database accounts with excessive permissions
• •Background jobs and reports that construct SQL from stored values

A concise message for developers is: keep SQL code and data structurally separate; bind all values, allowlist any unavoidable dynamic structure, and limit what the database account can do.