GPT on Question 18, Sep 24

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 string-built SQL, unsafe dynamic identifiers, or incorrect use of an ORM/query builder.

Main classes of SQL injection

1. In-band SQL injection

The attacker sends input and receives results through the same application response.

• •Error-based SQLi: Deliberately triggers database errors that reveal schema, query, or data details.
• •UNION-based SQLi: Alters a query so rows from another table or query appear in the normal response.

Common indicators: Database error messages, unexpected extra rows/columns, or responses changing substantially with special input.

2. Inferential or “blind” SQL injection

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

• •Boolean-based: A page, status code, response size, or other behavior differs based on a true/false condition.
• •Time-based: Database operations introduce a conditional delay, allowing information to be inferred from response timing.

Blind SQLi can be slower but remains serious because data may be extracted one bit or character at a time.

3. Out-of-band SQL injection

The vulnerable database is induced to communicate through another channel, such as DNS or an outbound network request. This is relevant when normal responses reveal little but the database server has unnecessary outbound connectivity.

4. Stacked-query injection

Some drivers and databases allow multiple statements in one request. Injection may then append an additional statement, potentially modifying data or configuration rather than merely reading it.

Whether this is possible depends on the database, API, and driver configuration.

5. Second-order SQL injection

Malicious input is stored safely at first, then later retrieved and concatenated into another SQL statement. The vulnerability occurs at the later use, not necessarily at the original input point.

This is why “the value came from our database” does not make it trusted.

6. Injection into non-value query elements

Parameters typically protect values, but they usually cannot represent SQL syntax such as:

• •Table or column names
• •Sort direction
• •ORDER BY fields
• •Operators
• •SQL fragments

If user input controls these elements, use a strict allowlist that maps external choices to developer-defined SQL identifiers—never direct concatenation.

Risk factors developers should recognize

• •Building queries with string concatenation, interpolation, or formatting
• •“Escaping” input instead of using parameters
• •Raw SQL features in ORMs
• •Dynamic SQL inside stored procedures
• •Overprivileged database accounts
• •Detailed database errors returned to users
• •Different code paths for search, reporting, filtering, and administrative tools
• •Numeric inputs treated as safe merely because they are expected to be numbers

Primary defenses

• 1.Use parameterized queries/prepared statements everywhere values are supplied.
• 2.Allowlist dynamic identifiers and query options.
• 3.Avoid dynamic SQL; if unavoidable, parameterize within it.
• 4.Use least-privileged database accounts, separated by service or function where practical.
• 5.Do not expose detailed database errors to clients; retain them in protected logs.
• 6.Validate input for business rules, while recognizing validation is not a substitute for parameterization.
• 7.Review stored procedures and ORM escape hatches for string-built SQL.
• 8.Restrict database-server outbound network access to reduce out-of-band impact.
• 9.Test both immediate and later reuse of stored values to identify second-order SQLi.
• 10.Add automated analysis and tests: SAST, DAST in staging, dependency checks, and targeted code review.

A useful briefing summary is: SQL injection is not primarily a “bad characters” problem; it is a failure to keep SQL code structurally separate from untrusted data.