GPT on Question 18, Oct 1

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL statement rather than 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: Database errors reveal schema details, query structure, or data.
• •UNION-based: An injected query combines attacker-selected results with the application’s normal result set.
• •Tautology/authentication bypass: Input alters a condition so it evaluates more broadly than intended.

2. Inferential or “blind” SQL injection

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

• •Boolean-based: Differences in pages, status codes, content length, or behavior reveal true/false results.
• •Time-based: Conditional database delays allow information to be inferred from response timing.

Blind SQLi can be subtle because the application may show no visible database errors.

3. Out-of-band SQL injection

The database is induced to communicate through another channel, such as DNS or an outbound network request. This typically depends on database-specific features and permissive egress controls.

4. Stacked or piggybacked queries

Input terminates the intended statement and adds one or more additional statements. Whether this works depends on the database driver and whether multi-statement execution is enabled.

5. Second-order SQL injection

Malicious input is stored safely at first but later retrieved and concatenated into another SQL query. Validation at initial entry may not catch it because exploitation happens in a different code path.

6. SQL injection in non-value contexts

Injection is not limited to quoted string values. Risk also appears in dynamically constructed:

• •Table or column names
• •ORDER BY clauses and sort direction
• •Operators
• •Pagination expressions
• •Stored-procedure calls
• •JSON/XML operators or database-specific syntax

Prepared-statement parameters often cannot represent identifiers, so these contexts require strict allowlists rather than escaping.

Common impact

SQLi may permit:

• •Reading or modifying sensitive records
• •Authentication or authorization bypass
• •Destructive database operations
• •Privilege escalation
• •File access or operating-system interaction where database privileges allow it
• •Availability attacks through expensive queries or locks

Developer guidance

• 1.Use parameterized queries/prepared statements everywhere.
• 2.Do not build SQL by string concatenation or interpolation.
• 3.Allowlist dynamic identifiers and sort options.
• 4.Use least-privileged database accounts, separating read, write, and administrative roles where possible.
• 5.Avoid exposing verbose database errors to clients; retain detailed errors only in protected logs.
• 6.Treat stored procedures and ORMs as safe only when they avoid dynamic SQL.
• 7.Validate input as defense in depth, not as a replacement for parameterization.
• 8.Re-parameterize stored data when it is later used in queries to prevent second-order injection.
• 9.Disable unnecessary multi-statement and dangerous database features.
• 10.Test authenticated APIs, background jobs, reporting/export features, and administrative interfaces, not just public forms.

A useful message for developers is: escaping is database- and context-dependent; parameterization separates code from data and is the primary fix.