GPT on Question 18, Sep 14

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a database query rather than as data. The main classes overlap—one issue may fit several categories.

1. In-band SQL injection

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

• •Error-based: Database errors reveal query structure, table or column names, DBMS details, or data.
• •UNION-based: An injected query combines attacker-selected results with the application’s normal result set.

Developer concern: Detailed database errors and dynamically concatenated queries make these issues easier to exploit.

2. Blind or inferential SQL injection

The application does not directly return database data, but behavior reveals whether an injected condition was true.

• •Boolean-based: Different content, status codes, redirects, or response lengths indicate true versus false.
• •Time-based: Conditional database delays allow facts to be inferred from response timing.

Developer concern: Removing error messages does not fix SQLi; seemingly minor response or timing differences can still act as a side channel.

3. Out-of-band SQL injection

The database is induced to communicate through a different channel, such as a DNS or network request. This depends on DBMS features, database privileges, and outbound network access.

Developer concern: Databases should not have unnecessary network access or privileges.

4. Stacked-query injection

Some drivers or APIs allow multiple SQL statements in one request. Injection can then add a separate statement rather than merely modifying the original one.

Developer concern: Driver settings can affect exploitability, but disabling multiple statements is only defense in depth—not a substitute for parameterization.

5. Second-order SQL injection

Malicious-looking input is stored safely at first, then later retrieved and concatenated into another SQL statement by a different workflow, job, or administrative tool.

Developer concern: Stored data is not automatically trusted. Parameterize queries even when values came from your own database.

6. Injection by query context

SQLi can occur in more places than quoted string values:

• •Numeric and date expressions
• •ORDER BY, sort direction, identifiers, and table or column names
• •LIKE patterns
• •LIMIT or pagination clauses
• •JSON/XML operators and DBMS-specific syntax
• •Stored procedures or ORM “raw query” features

Parameters generally protect values, not SQL identifiers or keywords. Dynamic identifiers and sort options should come from strict allowlists mapped to known-safe SQL fragments.

Related distinctions

• •First-order vs. second-order: Whether exploitation happens immediately or after data is stored and reused.
• •Read vs. write impact: SQLi may expose data, modify or delete records, bypass authorization, or invoke dangerous database features.
• •Authentication bypass: A consequence of SQLi in login logic, not a separate technical class.

Recommended developer guidance

• 1.Use prepared statements or parameterized queries everywhere.
• 2.Avoid string concatenation, interpolation, and ORM raw-query APIs.
• 3.Allowlists for identifiers, sort directions, and other non-parameterizable query parts.
• 4.Give application database accounts least privilege; separate read/write and administrative roles.
• 5.Return generic errors externally while logging details securely.
• 6.Restrict database outbound connectivity and disable unnecessary features.
• 7.Test delayed and background workflows for second-order injection.
• 8.Add code-review rules and automated SAST/DAST coverage, but do not treat a WAF as the primary fix.
• 9.Verify fixes across every execution path—the correct remediation is safe query construction, not filtering SQL characters.