GPT on Question 19, Sep 16

SQL injection (SQLi) occurs when untrusted input is interpreted as SQL syntax rather than as data. It is useful to classify SQLi both by how results are extracted and by where/when the injection occurs.

Main classes by exploitation technique

1. In-band SQL injection

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

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

Typical symptom: Unexpected records or detailed database errors appear in an HTTP response.

2. Inferential (“blind”) SQL injection

The application does not display query results directly, but its behavior reveals whether an injected condition was true.

• •Boolean-based blind SQLi: Responses differ—for example, content present versus absent—depending on a database condition.
• •Time-based blind SQLi: Deliberate database delays indicate whether a condition was true.

Typical symptom: Small, repeatable response-content or response-time differences caused by crafted input.

3. Out-of-band SQL injection

The database is induced to send information through another channel, such as a DNS or network request. This is less common and depends on database features and network access.

Typical symptom: Unexpected outbound connections from database infrastructure.

Other important classifications

4. Stacked-query injection

If the driver or database allows multiple statements in one call, injected input may append an additional SQL statement. This can turn data disclosure into data modification or administrative actions.

5. Second-order SQL injection

Malicious input is stored safely at first, then later inserted unsafely into a different SQL query. Validation at initial entry may therefore miss the actual vulnerable execution point.

Example pattern: A stored profile field is later concatenated into an administrative report query.

6. Injection into different query elements

Injection is not limited to string values. It can occur in:

• •Numeric values
• •Search and filter conditions
• •ORDER BY fields or sort direction
• •Table or column identifiers
• •Pagination clauses
• •Dynamic report builders
• •Stored procedures that construct dynamic SQL
• •ORM “raw query” or query-fragment APIs

Parameters protect values, but usually cannot represent identifiers or SQL keywords. Dynamic identifiers require strict allowlists.

What developers should do

• 1.Use parameterized queries/prepared statements everywhere.
  Never build SQL by concatenating, interpolating, or formatting untrusted values.

• 2.Allowlist dynamic identifiers.
  Map user choices such as "date" or "name" to hard-coded column names; do not insert the supplied text directly.

• 3.Avoid dynamic SQL where possible.
  Stored procedures and ORMs are not inherently safe if they concatenate strings or use raw SQL.

• 4.Apply least privilege.
  Application database accounts should have only required permissions; avoid administrative roles and unnecessary write access.

• 5.Return generic errors to clients.
  Log database details securely, but do not expose query text, schema names, or stack traces.

• 6.Treat stored data as untrusted.
  Parameterize every query at execution time, which also addresses second-order SQLi.

• 7.Test systematically.
  Include code review, SAST/DAST, dependency checks, and authorized penetration testing. Focus on all inputs: URL parameters, JSON fields, headers, cookies, uploaded-file metadata, and internal service messages.

• 8.Use a WAF only as defense in depth.
  It may detect common attempts but does not replace correct query construction.

The core briefing message is: SQL injection is fundamentally a query-construction flaw. Keep SQL structure fixed, bind values as parameters, and allowlist any structure that must be dynamic.