GPT on Question 18, Sep 20

SQL injection (SQLi) occurs when untrusted input is interpreted as SQL syntax rather than as data. The classes below overlap: some describe how results are retrieved, while others describe where or when the injection executes.

Main SQLi classes

1. In-band SQL injection

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

• •Error-based SQLi: Deliberately triggers database errors that disclose schema, query, or data details.
• •UNION-based SQLi: Alters a query so results from another compatible query are included in the application’s normal response.

Typical indicator: unusual database errors, unexpected extra rows/columns, or input that changes response content.

2. Blind or inferential SQL injection

The application does not directly return database output, so information is inferred from behavioral differences.

• •Boolean-based: A condition that evaluates true produces a different page, status code, record count, or response length than one that evaluates false.
• •Time-based: Conditional database delays allow facts to be inferred from response timing.

Blind SQLi can be serious even when errors and query output are hidden; exploitation is merely slower.

3. Out-of-band SQL injection

Results or signals leave through a different channel, such as database-initiated DNS or HTTP traffic. This depends on database features, network egress, and service-account permissions.

Typical indicator: unexpected outbound connections from database servers.

4. Stacked or piggy-backed queries

Input terminates or extends the intended statement and adds another statement. Whether this works depends on the database, driver, and API configuration. Impact can include modifying data or administrative state, not just reading it.

5. Second-order SQL injection

Malicious-looking input is safely stored initially but later retrieved and concatenated into a new SQL statement by another workflow, report, batch job, or administrative tool.

This is commonly missed because validation occurs at input time while the vulnerable SQL construction happens elsewhere.

6. Injection in non-value contexts

Parameterized queries protect values, but developers sometimes dynamically construct SQL elements that cannot normally be bound as parameters, including:

• •Table or column names
• •Sort direction and ORDER BY fields
• •Operators
• •Pagination clauses
• •Entire filters or fragments

These require strict allowlists or safe query-building APIs—not escaping alone.

7. Dynamic SQL inside stored procedures

Stored procedures are not automatically safe. A procedure that concatenates arguments into dynamic SQL can still be injectable. Procedures using fixed SQL and properly bound parameters are generally safer.

Common root causes

• •String concatenation or interpolation when building queries
• •“Sanitization” or manual quote escaping instead of parameter binding
• •ORM escape hatches such as raw-query methods
• •Dynamic identifiers without allowlisting
• •Overprivileged application database accounts
• •Inconsistent handling in background jobs, reporting tools, or stored procedures

Recommended defenses

• 1.Use prepared statements and bound parameters everywhere data values enter SQL.
• 2.Allowlist dynamic identifiers and sort options by mapping user choices to hard-coded SQL identifiers.
• 3.Avoid raw SQL APIs where practical; review every unavoidable use.
• 4.Apply least privilege: separate read/write/migration accounts and prevent the application account from administering the database.
• 5.Return generic errors to clients while retaining detailed server-side logs.
• 6.Validate input for business correctness, but do not treat validation as a substitute for parameterization.
• 7.Review second-order paths, including exports, reports, scheduled jobs, and administrative screens.
• 8.Restrict database network egress to reduce out-of-band impact.
• 9.Test both response content and timing, and inspect database/application logs during authorized assessments.
• 10.Use SAST, dependency scanning, and focused code review to find concatenated query construction. A WAF can provide defense in depth but is not a primary fix.

A concise message for developers is: never build SQL syntax by concatenating untrusted data; bind values, allowlist unavoidable identifiers, and minimize database privileges.