GPT on Question 19, Sep 21

SQL injection 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.

• •UNION-based: Manipulates a query so it returns data from additional tables.
• •Error-based: Deliberately triggers database errors that reveal schema, query, or data details.

2. Blind or inferential SQL injection

The application does not directly return database data, so the attacker infers it from behavior.

• •Boolean-based: Observes differences between “true” and “false” responses, such as content, status codes, or row counts.
• •Time-based: Causes conditional database delays and infers information from response timing.

3. Out-of-band SQL injection

The database is induced to send information through another channel, such as DNS or an outbound network request. This depends on database features and network permissions.

4. Stacked-query injection

Input terminates the intended statement and adds another SQL statement. Whether this works depends on the database driver and configuration. It can enable data modification or administrative actions, not merely data retrieval.

5. Second-order SQL injection

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

6. Dynamic-query and identifier injection

Values are not the only risk. User-controlled table names, column names, sort directions, operators, or SQL fragments can alter query structure. These elements generally cannot be protected with ordinary value parameters and require strict allowlists.

What developers should do

• 1.Use parameterized queries/prepared statements for every data value.
• 2.Never build SQL through string concatenation or interpolation, including stored procedures and internal/admin tools.
• 3.Allowlist dynamic identifiers and query options; map user choices to hard-coded SQL identifiers.
• 4.Use least-privileged database accounts and separate read/write or administrative roles.
• 5.Avoid exposing database errors to clients; log them securely instead.
• 6.Treat stored data as untrusted to prevent second-order injection.
• 7.Review ORM escape hatches, raw-query APIs, dynamic filters, and query builders.
• 8.Add automated security tests and code review rules focused on every SQL construction point.
• 9.Use a WAF only as defense in depth, not as a replacement for safe query construction.

The key briefing point is: escaping and input validation are secondary controls; parameterization and strict structural allowlisting are the primary defenses.