GPT on Question 18, Sep 23

SQL injection (SQLi) occurs when untrusted input is interpreted as part of a SQL command rather than strictly as data. The root cause is usually dynamic query construction through string concatenation.

Main classes of SQL injection

1. In-band SQLi

The attacker submits input and receives results through the same application channel.

• •Error-based: Database errors reveal query structure, table or column names, data types, or sometimes data itself.
• •UNION-based: An injected query combines attacker-selected data with the application’s legitimate result set.

2. Blind / inferential SQLi

The application does not directly return database data or useful errors, but behavior still reveals information.

• •Boolean-based: Different application responses—such as “record found” versus “not found”—allow facts to be inferred one bit at a time.
• •Time-based: Deliberate database delays are used to distinguish true and false conditions by measuring response time.

3. Out-of-band SQLi

The database is induced to communicate through a different channel, such as DNS or an outbound network request. This is less common and depends on database features and outbound connectivity.

4. Stacked-query injection

If the driver or database permits multiple statements in one request, injected input may append an additional SQL statement. Impact can extend beyond disclosure to modification, deletion, or administrative operations.

5. Second-order SQLi

Malicious input is safely stored initially but later retrieved and concatenated into another SQL statement. The vulnerability therefore triggers in a different workflow from where the input entered the system.

Other useful classifications

SQLi can also be categorized by where input lands:

• •String, numeric, or date expressions
• •ORDER BY, column, or table identifiers
• •LIKE patterns
• •Stored procedures or dynamically generated SQL
• •JSON/XML query features or ORM “raw query” interfaces

Prepared-statement parameters protect values, but usually cannot parameterize identifiers or SQL keywords. Dynamic identifiers should come from strict server-side allowlists.

Developer guidance

• 1.Use parameterized queries or prepared statements everywhere.
• 2.Avoid string interpolation, concatenation, and hand-built escaping.
• 3.For dynamic sort fields, table names, or directions, map user choices to fixed allowlisted constants.
• 4.Give the application database account only the permissions it needs.
• 5.Disable multi-statement execution unless required.
• 6.Return generic client errors while logging detailed database errors securely.
• 7.Treat stored data as untrusted when it is reused in later queries.
• 8.Review ORM escape hatches, raw SQL, stored procedures, and query builders carefully.
• 9.Add automated tests for every database-facing input path.
• 10.Use SAST/DAST and database monitoring as secondary controls—not substitutes for parameterization.

A useful summary for developers is: SQLi is a separation failure between code and data; parameterization preserves that separation.