GPT on Question 19, Oct 2

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL statement rather than as data.

Main classes

1. In-band SQL injection

The attacker sends the payload and receives results through the same application channel.

• •Error-based: Database errors reveal schema, query structure, or data.
• •UNION-based: An injected UNION causes the query to return data from other tables.
• •Tautology/authentication bypass: Input changes a condition so it is always true.
• •Stacked or piggybacked queries: If supported, an attacker appends additional SQL statements.

2. Inferential (“blind”) SQL injection

The application does not directly display database results, but its behavior reveals information.

• •Boolean-based: Responses differ depending on whether an injected condition is true or false.
• •Time-based: Conditional database delays allow facts to be inferred from response times.
• •Content/status-based: Differences in page content, HTTP status, redirects, or record counts leak the result.

3. Out-of-band SQL injection

The database is induced to communicate through another channel—such as DNS or an outbound network request. This is less common and depends on database features, privileges, and network access.

4. Second-order SQL injection

Malicious input is stored safely at first, then later inserted unsafely into a different SQL statement. Validation only at initial entry often misses this class.

Other useful distinctions

• •First-order vs. second-order: Executed immediately versus stored and triggered later.
• •Read vs. write/administrative impact: SQLi may expose data, modify or delete it, bypass authorization, or invoke privileged database functionality.
• •Injection location: Values, dynamic table/column names, sort directions, search filters, JSON/XML operators, or ORM-generated queries. Parameterization generally protects values, but not SQL identifiers or keywords.

Developer guidance

• 1.Use parameterized queries/prepared statements everywhere.
• 2.Never build SQL by concatenating input, including values previously stored in the database.
• 3.For dynamic identifiers such as column names or sort order, use a strict allowlist and code-side mapping; placeholders usually cannot represent identifiers.
• 4.Treat stored procedures and ORMs as safe only if they do not construct dynamic SQL unsafely.
• 5.Run the application with least-privilege database credentials; separate read, write, and administrative roles.
• 6.Avoid exposing detailed database errors to clients; log them securely instead.
• 7.Add automated tests and code review rules for query construction, and use SAST/DAST as secondary controls.
• 8.Do not rely on escaping, input filtering, or a WAF as the primary defense. Parameterization is the core control.