GPT on Question 19, Sep 25

SQL injection occurs when untrusted input is interpreted as part of a SQL command rather than as data. The main classes describe either how the injection is triggered or how results are extracted.

1. In-band SQL injection

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

• •Error-based: Database error messages reveal schema, query structure, or data.
• •UNION-based: An injected query combines attacker-selected results with the application’s normal result set.
• •Stacked-query injection: If the driver/database permits multiple statements, input may cause additional commands to execute.

2. Inferential (“blind”) SQL injection

The application does not directly return database output, but its behavior reveals whether an injected condition was true.

• •Boolean-based: Differences in page content, status codes, row counts, or application behavior leak information.
• •Time-based: Deliberate database delays are used to infer results from response timing.

“Blind” does not mean harmless—it can still enable extensive data extraction.

3. Out-of-band SQL injection

The database is induced to communicate through another channel, such as a network request or DNS lookup. This depends on database features, privileges, and network access, but may bypass limited application responses.

4. Second-order SQL injection

Malicious input is stored safely at first, then later incorporated unsafely into another dynamically constructed query. Validation at initial entry alone therefore does not prevent it.

Common injection contexts

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

• •Search and filter parameters
• •Numeric values
• •ORDER BY, column, or table names
• •Reporting and administrative tools
• •Stored procedures that construct dynamic SQL
• •JSON/API fields, headers, cookies, and background jobs

Core guidance for developers

• 1.Use parameterized queries/prepared statements everywhere. Never concatenate values into SQL.
• 2.Allowlist identifiers. Table names, column names, sort directions, and SQL keywords usually cannot be bound as parameters; map user choices to predefined constants.
• 3.Avoid dynamic SQL. If unavoidable, parameterize values and tightly constrain generated structure.
• 4.Treat stored data as untrusted. Parameterize queries even when values came from your own database.
• 5.Use least-privileged database accounts. Separate read-only, application, migration, and administrative roles.
• 6.Suppress detailed database errors in user responses, while retaining useful server-side logging.
• 7.Do not rely on escaping, input filtering, or a WAF as the primary defense. They are supplementary controls.
• 8.Test systematically: code review, SAST/DAST, dependency checks, and security tests for every database-access path.

A useful briefing sentence is: “SQL injection is prevented by keeping query structure fixed and sending all untrusted values separately as typed parameters.”