GPT on Question 19, Sep 17

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL command rather than 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: Database errors reveal schema details, query structure, or data.
• •UNION-based: An injected query combines attacker-selected results with the application’s legitimate result set.

2. Blind or inferential SQL injection

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

• •Boolean-based: Responses differ depending on whether an injected condition evaluates true or false.
• •Time-based: Deliberate database delays indicate whether a condition was true.

Blind SQLi can still extract significant data, although more slowly.

3. Out-of-band SQL injection

Data is exfiltrated through another channel—such as database-triggered DNS or network requests—rather than through the application response. This depends on database features, network access, and permissions.

4. Stacked-query injection

The database driver accepts multiple statements in one request, allowing an attacker to append additional operations. Potential impact includes modifying data, creating accounts, or changing schema—not just reading records.

5. Second-order SQL injection

Malicious input is stored safely at first but later inserted unsafely into another SQL statement. For example, a value saved during registration may become dangerous when used later by an administrative report or background job.

SQLi can occur in more than string values

Developers should consider every query component that may be dynamically constructed:

• •Numeric and string parameters
• •ORDER BY columns or sort direction
• •Table and column names
• •Search, filter, and pagination clauses
• •JSON/XML values passed into SQL functions
• •Stored-procedure calls
• •Administrative scripts, reports, and ETL jobs

Primary defenses

• 1.Use parameterized queries/prepared statements everywhere.
  Parameters separate SQL structure from values.

• 2.Do not build SQL by concatenating or interpolating input.
  Escaping is database-specific and is not a reliable primary defense.

• 3.Allowlist identifiers that cannot be parameterized.
  For dynamic column names, sort direction, or table names, map fixed user choices to hard-coded SQL fragments.

• 4.Use least-privileged database accounts.
  The application account should not own schemas, create users, or access unrelated databases.

• 5.Treat stored procedures and ORMs as safe only when used correctly.
  They remain vulnerable when they dynamically concatenate SQL.

• 6.Suppress detailed database errors in production while preserving them in protected logs.

• 7.Test all data flows, including delayed reuse of stored data.
  Use code review, SAST/DAST, dependency checks, and security tests for second-order and blind SQLi.

A useful rule for developers is: all SQL structure must come from trusted code; all external values must be bound as parameters.