GPT on Question 18, Sep 17

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: Deliberately triggers database errors that may reveal schema details, query structure, database type, or data.
• •UNION-based: Alters a query so results from another table or query are appended to the legitimate response.

2. Inferential or “blind” SQL injection

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

• •Boolean-based: Causes the query condition to evaluate true or false and observes differences in content, status codes, redirects, or response sizes.
• •Time-based: Uses conditional database delays and infers results from response timing. This tends to be slow but works even when responses otherwise look identical.

3. Out-of-band SQL injection

The database is induced to communicate over another channel, such as DNS or HTTP. This depends on database features, network egress, and service-account permissions. It is particularly important to restrict outbound connectivity from database servers.

4. Stacked or piggybacked queries

Input terminates the intended statement and adds another statement. Whether this works depends on the database, driver, and whether multi-statement execution is enabled. Potential impact can extend beyond reading data to modification or administrative operations.

5. Second-order SQL injection

Malicious-looking input is initially stored safely, but later retrieved and concatenated into a new SQL statement. Validation only at initial entry does not prevent this; every query construction point must use parameters.

Related injection locations

SQLi is not limited to obvious login or search fields. It can occur through:

• •URL and body parameters
• •HTTP headers and cookies
• •JSON or XML fields
• •Sorting, filtering, column, or table selectors
• •Stored values later reused by jobs or reports
• •ORM “raw query” and dynamic query APIs

Key guidance for developers

• 1.Use parameterized queries/prepared statements everywhere.
  Do not build SQL by concatenating, interpolating, or formatting input.

• 2.Allowlist identifiers.
  Parameters generally cannot represent table names, column names, or sort directions. Map user-facing choices to fixed application constants.

• 3.Avoid relying on escaping or input filtering.
  These are fragile across database dialects, encodings, and query contexts.

• 4.Apply least privilege.
  Application accounts should have only required permissions; avoid administrative roles and unnecessary filesystem, network, or procedure access.

• 5.Suppress detailed database errors externally.
  Log useful details internally, but return generic errors to clients.

• 6.Disable unnecessary capabilities.
  Examples include multi-statement execution, dangerous stored procedures, and database-server outbound network access.

• 7.Test all execution paths.
  Include asynchronous jobs, reporting systems, exports, admin tools, and stored-procedure dynamic SQL—not just public endpoints.

A useful developer rule is: all data values are bound parameters; all SQL structure is chosen from trusted, fixed code.