GPT on Question 18, Sep 29

SQL injection (SQLi) occurs when untrusted input is interpreted as SQL syntax rather than data. The root cause is usually dynamic query construction through string concatenation instead of parameterized queries.

Main SQLi classes

1. In-band SQL injection

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

• •Error-based SQLi: Deliberately triggers database errors that may reveal schema details, query structure, or data.
• •UNION-based SQLi: Alters a query with a set-combining operation so data from another table appears in the normal response.

This is most practical when database errors or query results are exposed to users.

2. Blind or inferential SQL injection

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

• •Boolean-based: The attacker observes differences in content, status codes, redirects, or response size.
• •Time-based: The attacker causes a conditional database delay and infers the result from response time.

“Blind” does not mean harmless; data can be extracted one bit or character at a time.

3. Out-of-band SQL injection

The database is induced to communicate through another channel, such as a DNS or HTTP request. This depends on database features, permissions, and outbound network access. Egress filtering and least-privileged database accounts significantly reduce the risk.

4. Stacked-query or piggybacked injection

If the driver and database allow multiple statements in one call, attacker-controlled input may terminate the intended statement and append another. Impact can include data modification, privilege changes, or destructive operations.

5. Second-order SQL injection

Malicious input is initially stored safely or without immediate effect. It becomes dangerous later when another component retrieves it and concatenates it into a new SQL statement. Validation at the original input boundary alone does not prevent this; every query construction point must be safe.

6. Stored-procedure and dynamic-SQL injection

Stored procedures are not automatically safe. They remain vulnerable if they build SQL strings internally or accept untrusted input for identifiers, clauses, or commands. Procedures using static SQL with properly bound parameters are generally safer.

Injection contexts developers should recognize

SQLi is not limited to quoted string values. Input can enter:

• •Numeric values
• •String literals
• •LIKE patterns
• •ORDER BY, column names, or table names
• •Pagination and limit clauses
• •JSON/XML operators and database-specific expressions
• •ORM “raw query” or query-fragment APIs

Parameters typically protect values, not SQL identifiers or keywords. Dynamic column names, sort directions, and table names should be selected from strict allowlists.

Primary defenses

• 1.Use parameterized queries or prepared statements everywhere.
• 2.Avoid string concatenation and interpolation for SQL.
• 3.Allowlist structural choices such as sort column and direction.
• 4.Use least-privileged database accounts and separate read/write roles where practical.
• 5.Suppress detailed database errors from user-facing responses while retaining secure server-side logs.
• 6.Review stored procedures, ORM escape hatches, and raw SQL.
• 7.Apply defense in depth: input constraints, egress controls, monitoring, and query timeouts.
• 8.Test both immediate and second-order paths, including background jobs, reporting tools, and admin interfaces.

Escaping input is database- and context-specific and should not be treated as a substitute for parameterization. A useful code-review rule is: untrusted data may become a bound value, but must never become SQL syntax.