GPT on Question 18, Sep 21

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL statement rather than strictly as data. The most useful classes for a developer briefing 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 reveal schema names, query structure, data types, or sometimes data.
• •UNION-based: Alters a query so results from another table or query are appended to the normal response.

These are often visible when the application returns detailed database errors or directly renders query results.

2. Blind or inferential SQL injection

The application does not display database results or useful errors, but its behavior still reveals whether a condition was true.

• •Boolean-based: The response changes—content, status code, row count, redirect, etc.—depending on whether an injected condition evaluates true or false.
• •Time-based: The database is induced to delay execution conditionally, allowing information to be inferred from response time.

Blind SQLi can be slower but remains serious even when error messages are suppressed.

3. Out-of-band SQL injection

Data is transmitted through a different channel, such as a database-initiated DNS or network request. This depends heavily on the database engine, enabled features, service-account privileges, and outbound network access.

4. Stacked-query injection

The input terminates the intended statement and adds one or more additional statements. Whether this works depends on the database driver and configuration. The impact can extend beyond reading data to modifying records or database configuration.

5. Second-order SQL injection

Malicious input is stored safely at first but later retrieved and incorporated unsafely into another SQL statement. This is commonly missed because the initial write operation appears harmless.

Example pattern: a value entered during account creation is stored, then later concatenated into an administrative reporting query.

6. Injection into non-value query elements

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

• •Table or column names
• •ORDER BY and sort directions
• •Search filters
• •Pagination clauses
• •Numeric expressions
• •Stored-procedure calls
• •JSON/XML operators or database-specific syntax

Parameterized queries generally protect values, but identifiers and SQL keywords usually require strict allowlisting or query redesign.

Primary defenses

• 1.Use parameterized queries/prepared statements everywhere.
  Do not build SQL by concatenating, interpolating, or formatting user-controlled values.

• 2.Allowlist dynamic identifiers.
  Map user-facing choices such as "date" or "name" to fixed, developer-defined SQL fragments.

• 3.Treat stored data as untrusted.
  Parameterize queries even when input came from your own database to prevent second-order SQLi.

• 4.Use least-privileged database accounts.
  Separate read-only, application-write, migration, and administrative roles where practical.

• 5.Suppress detailed database errors in client responses.
  Log them securely on the server, with sensitive values redacted.

• 6.Restrict database network egress and dangerous features.
  This reduces out-of-band and post-exploitation impact.

• 7.Test every data path.
  Include headers, cookies, JSON fields, bulk imports, background jobs, reporting tools, and administrative interfaces—not just form fields.

• 8.Do not rely on escaping, input filtering, a WAF, or stored procedures alone.
  They can be supplemental controls, but none replaces safe query construction. Stored procedures are vulnerable if they construct dynamic SQL internally.

For triage, treat confirmed SQLi as high severity because impact may include authentication bypass, data disclosure or modification, and—in some configurations—broader database or host compromise.