GPT on Question 19, Sep 22

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL statement rather than as data. The main classes describe either how results are observed or when/how injected SQL executes.

1. In-band SQL injection

The attacker injects 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 normal result set.

2. Blind or inferential SQL injection

The application does not directly display database output, so information is inferred from behavior.

• •Boolean-based: Responses differ depending on whether an injected condition is true or false.
• •Time-based: Delays or response timing indicate whether a condition was true.

3. Out-of-band SQL injection

The database sends information through a separate channel, such as a network request. This is less common and depends on database features, permissions, and network access.

4. Stacked-query injection

Input terminates the intended statement and adds another SQL statement. Whether this works depends on the database and driver allowing multiple statements. Impact can include modification or deletion of data.

5. Second-order or stored SQL injection

Malicious input is stored safely at first, but later incorporated unsafely into another SQL query. Validation only at initial entry does not prevent this; every query construction point must be safe.

Injection contexts

Any of these classes may occur in different SQL contexts:

• •String or numeric values
• •Search and filtering clauses
• •ORDER BY, column, table, or direction identifiers
• •Dynamic IN lists
• •Stored procedures and dynamic SQL
• •ORM “raw query” or expression APIs

What developers should do

• 1.Use parameterized queries/prepared statements everywhere.
• 2.Never build SQL by concatenating or interpolating untrusted values.
• 3.For identifiers that cannot be parameterized, use strict allowlists and map user choices to hard-coded identifiers.
• 4.Avoid dynamic SQL inside stored procedures; stored procedures are not inherently safe.
• 5.Use least-privileged database accounts and separate read/write roles where practical.
• 6.Return generic errors to users; log detailed database errors securely.
• 7.Treat escaping as a last resort, not a replacement for parameters.
• 8.Test raw SQL, ORM escape hatches, reporting features, and stored-data flows specifically.
• 9.Add code review rules and automated SAST/DAST checks for SQL construction.

The core message for developers: SQL structure should be fixed by code; user-controlled data should reach the database only through typed parameters or strict allowlist mappings.