GPT on Question 18, Sep 30

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL statement rather than strictly as data. The major classes are:

1. In-band SQL injection

The attacker injects SQL and receives results through the same application response.

• •Error-based SQLi: Database errors reveal schema details, query structure, data types, or values.
• •UNION-based SQLi: An injected UNION combines attacker-selected data with the application’s legitimate result set.

2. Inferential (“blind”) SQL injection

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

• •Boolean-based blind: Responses differ depending on whether an injected condition evaluates true or false.
• •Time-based blind: Conditional database delays are used to infer results from response timing.

3. Out-of-band SQL injection

Data is exfiltrated through a separate channel, such as DNS or an outbound network request initiated by a database feature. This is less common and generally requires both suitable database functionality and outbound connectivity.

4. Stacked or piggybacked queries

Input terminates the intended statement and adds another SQL statement. Whether this works depends on the database, driver, and whether multiple statements are permitted.

5. Second-order SQL injection

Malicious input is stored safely at first, but later retrieved and concatenated into another SQL statement. Validation only at initial entry may therefore miss it.

Other useful classifications

SQLi can also be categorized by where untrusted input appears:

• •String, numeric, or date expressions
• •Identifiers such as table, column, or sort-order names
• •LIKE, ORDER BY, LIMIT, or pagination clauses
• •Stored procedures or dynamically generated SQL
• •JSON/XML operators and ORM “raw query” escape hatches

Primary defenses

• 1.Use parameterized queries/prepared statements for all values.
  ```sql
  SELECT id, name FROM users WHERE email = ?
  ```
• 2.Do not build SQL with string concatenation or interpolation.
• 3.Allowlist identifiers that cannot be parameterized, such as sort columns:
  ```text
  requested "name" → predefined SQL fragment "name ASC"
  ```
• 4.Avoid dynamic SQL inside stored procedures, or parameterize it correctly.
• 5.Use least-privileged database accounts and separate read/write or administrative roles.
• 6.Return generic errors to clients while logging detailed errors securely.
• 7.Treat escaping as a secondary control, not a replacement for parameters.
• 8.Test every execution path, including delayed/second-order uses, background jobs, exports, and ORM raw-query features.
• 9.Use timing-aware testing for blind SQLi, while accounting for normal network variance.
• 10.Restrict database outbound network access to reduce out-of-band impact.

A concise message for developers is: input validation is helpful, but the core fix is keeping SQL code and data structurally separate through parameterization.