GPT on Question 18, Sep 18

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL statement rather than strictly 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: Intentionally triggers database errors that reveal query structure, schema details, or data.
• •UNION-based: Alters a query so it combines its intended results with rows from another query.

2. Inferential or “blind” SQL injection

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

• •Boolean-based: Infers information from differences in responses, such as page content, HTTP status, or row counts.
• •Time-based: Infers information from response delays caused by conditional database operations.

3. Out-of-band SQL injection

Data is extracted through a separate channel, such as database-initiated DNS or network requests. This is less common and depends on database features and outbound network access.

4. Stacked-query injection

Input terminates the intended statement and adds additional SQL statements. Whether this works depends on the database, driver, and configuration. The impact may include data modification or administrative operations.

5. Second-order SQL injection

Malicious input is stored safely at first, then later incorporated unsafely into another SQL statement. Validation only at initial entry often misses this class.

6. Stored procedure and dynamic-SQL injection

Stored procedures are not inherently safe. Procedures that concatenate input into dynamic SQL can remain injectable, even if the application calls the procedure using parameters.

Common injection contexts

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

• •Numeric values
• •LIKE patterns
• •IN lists
• •Sort columns or directions
• •Table or column identifiers
• •Pagination clauses
• •JSON/XML operators and database-specific syntax

Parameterization usually protects values, but identifiers and SQL keywords cannot generally be bound as parameters. Those should be selected from strict allowlists.

Developer guidance

• 1.Use parameterized queries/prepared statements everywhere.
• 2.Do not construct SQL through string concatenation or interpolation.
• 3.Allowlist dynamic identifiers, such as sortable columns and ASC/DESC.
• 4.Avoid dynamic SQL inside stored procedures, or parameterize it correctly.
• 5.Use least-privileged database accounts; separate read-only and write roles where practical.
• 6.Return generic errors to clients and keep database details in protected logs.
• 7.Treat stored data as untrusted to prevent second-order injection.
• 8.Review ORM escape hatches, raw-query APIs, query builders, and hand-built fragments.
• 9.Restrict database outbound network access to reduce out-of-band risk.
• 10.Test both responses and side effects, including timing differences and delayed use of stored values.

Escaping alone is fragile and database-specific; it should not replace parameterization and structural allowlisting.