GPT on Question 19, Sep 27

SQL injection occurs when untrusted input is interpreted as SQL syntax rather than as data. The most useful way to brief developers is to group attacks by how they extract or affect data.

Main classes

1. In-band SQL injection

The attacker uses the application’s normal response channel to obtain results.

• •UNION-based: Manipulates a query so it returns data from another table or query.
• •Error-based: Deliberately triggers database errors that reveal schema details or data.
• •Authentication/logic bypass: Alters conditions in a query so checks evaluate differently than intended.

Typical sign: Unexpected records, database error messages, or bypassed authorization.

2. Blind or inferential SQL injection

The application does not directly display database results, so the attacker infers information from behavior.

• •Boolean-based: Observes differences between “true” and “false” responses, such as page content, status codes, or result counts.
• •Time-based: Causes conditional delays and infers data from response timing.

Important: Suppressing database errors does not prevent SQL injection; it often only turns it into blind injection.

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 and network permissions.

Mitigation: Restrict database outbound connectivity and disable unnecessary database capabilities.

4. Stacked-query injection

If the driver or database permits multiple statements in one call, injected input may add a separate SQL statement. This can allow data modification, account creation, or destructive operations.

Mitigation: Disable multi-statement execution where possible and give the application database account minimal privileges.

5. Second-order SQL injection

Malicious input is stored safely at first but later incorporated unsafely into a different SQL query. For example, a saved profile field might later be used to construct an administrative report query.

Key lesson: Previously stored or “internal” data must not be considered trusted when building SQL.

6. Injection into non-value query elements

Parameterized queries generally protect values, but many applications dynamically construct other SQL elements:

• •Table or column names
• •Sort direction or ORDER BY fields
• •Operators
• •List structure
• •SQL fragments used for filters
• •Stored procedure or function names

These usually cannot be safely parameterized in the same way as values. Use strict allowlists and map user-facing options to fixed SQL identifiers.

Root causes

Common causes include:

• •String concatenation or interpolation when building SQL
• •Misusing an ORM’s “raw query” features
• •Dynamically assembled filters and report queries
• •Stored procedures that themselves concatenate SQL
• •Assuming numeric input, stored data, or internal API input is safe
• •Relying on escaping instead of parameter binding

Required developer controls

• 1.Use prepared statements and bound parameters for every data value.
• 2.Never concatenate user-controlled data into SQL.
• 3.Allowlist dynamic identifiers and query structure.
• 4.Use least-privilege database accounts; separate read-only and write roles where practical.
• 5.Disable multiple statements and unnecessary database features.
• 6.Avoid exposing database errors to users, while retaining detailed server-side logs.
• 7.Treat stored and service-to-service data as untrusted.
• 8.Review raw SQL and dynamic ORM APIs as security-sensitive code.
• 9.Test authorization separately: parameterization prevents injection, not unauthorized access to valid records.
• 10.Use automated testing and code review, but do not rely on a WAF as the primary control.

A concise rule for developers is:

If input affects a SQL value, bind it as a parameter. If it affects SQL structure, select the structure from a fixed allowlist—never paste the input into the query.