Claude on Question 19, Sep 18

SQL Injection: A Briefing Taxonomy

The Root Cause (lead with this)

Every SQL injection has the same cause: untrusted input crosses the boundary from data into code. When you build a query by concatenating strings, the database parser can't tell which characters came from your developer and which came from an attacker. Parameterized queries fix this by sending the query structure and the data over separate channels — the data can never be re-parsed as syntax.

Everything below is a variation on that one bug.

Classification 1: By How the Attacker Gets Results Back

This is the classic taxonomy and shapes how your team should think about detection.

Key point for developers: blind and out-of-band variants mean "we don't display database errors" and "the page looks the same" are not mitigations. Automated tooling extracts entire databases through a one-bit-at-a-time boolean oracle.

Classification 2: By Injection Context

This matters more for code review, because it tells you where to look.

Quoted string context — the classic. Attacker breaks out with ', hence ' OR '1'='1.

Numeric context — no quote to escape, so any concatenated integer is immediately exploitable: id=1 OR 1=1. Developers frequently assume "it's just an ID, it's a number" and skip parameterization. Very common finding.

Stacked queries — ; DROP TABLE audit_log--. Whether this works depends on the driver's multi-statement support (historically enabled in .NET/SQL Server and PHP PDO with certain settings, disabled in many MySQL drivers by default). Don't rely on it being off.

Non-parameterizable positions — this is the trap that catches otherwise careful teams. You cannot bind a parameter for:

• •Table or column names
• •ORDER BY <column> and ASC/DESC
• •LIMIT / TOP in some engines
• •Portions of dynamically assembled IN clauses

These require a strict allowlist: map user input (e.g., sort=date) to a hardcoded, server-side constant. Never pass the string through.

Second-order (stored) injection — input is stored safely via a parameterized insert, then later read back out of the database and concatenated into a different query — a reporting job, an admin panel, a batch process. Your input-validation layer never sees it. This defeats "we sanitize at the edge" architectures and is why parameterization must be universal, not perimeter-based.

Dynamic SQL inside stored procedures — calling a proc with bound parameters gives zero protection if the proc body does EXEC('SELECT * FROM t WHERE x = ''' + @p + ''''). Stored procedures are not inherently safe; review their bodies. Use sp_executesql with parameters, not string EXEC.

Encoding and charset edge cases — multibyte character set mismatches have historically defeated escaping functions (the classic GBK/addslashes bypass), and double-decoding bugs can reintroduce metacharacters after validation. Another reason escaping is a weak control.

Non-obvious input sources — HTTP headers, cookies, User-Agent, JSON and XML bodies, uploaded file contents, message queue payloads, and data from third-party APIs. "User input" means anything not written by your developers.

Classification 3: Adjacent Families

• •ORM / query-builder injection — raw fragments (.whereRaw(), @Query with string concat, JPQL/HQL interpolation) reintroduce the vulnerability inside a "safe" framework. Grep for the raw-query escape hatches in your stack.
• •NoSQL injection — operator injection in document stores (submitting {"$ne": null} where a string was expected), or server-side JavaScript evaluation. Same root cause, different syntax.
• •ORM leaks / mass assignment — not SQLi, but often found in the same review.

Impact Classes (for risk framing)

Beyond reading data: authentication bypass, data modification and destruction, reading files from the DB host, writing webshells, and in some configurations remote code execution (xp_cmdshell, PostgreSQL COPY ... FROM PROGRAM, MySQL UDFs). A SQLi in a low-value app that shares a database server with high-value systems is a lateral-movement path, not a low-severity finding.

Controls, in Priority Order

• 1.Parameterized queries with static SQL strings. This is the control. Everything else is supplementary.
• 2.Allowlist mapping for identifiers, sort columns, and any structural element that can't be bound.
• 3.Stored procedures — only if they avoid dynamic SQL internally.
• 4.Escaping is a last resort, used only when the first three are genuinely impossible, and it must be database- and charset-correct.
• 5.Least privilege for DB accounts. Separate read and write credentials, no DDL rights for application users, no DBA/sa. This caps the blast radius when control #1 fails.
• 6.Generic error pages plus detailed server-side logging. Reduces error-based attacks and speeds detection — but remember it doesn't stop blind SQLi.
• 7.Detection and testing: SAST rules flagging concatenation into query sinks, DAST or sqlmap runs in CI against a staging instance, and alerting on query-error spikes or unusual response-time patterns.
• 8.WAF as a speed bump only. Useful for buying time during patching; trivially bypassable with encoding and comment obfuscation.

Code Review Checklist to Hand Out

• •Any string concatenation, interpolation, +, %s, f-string, or template literal producing SQL → finding
• •Numeric parameters concatenated "because they're integers" → finding
• •ORDER BY, table names, or column names built from request data without an allowlist → finding
• •Raw-query escape hatches in the ORM → review individually
• •Stored procedure bodies using EXEC on a concatenated string → finding
• •Queries built from data read out of the database → second-order review
• •Any query built from headers, cookies, or file contents → treat as untrusted

A good closing message for the team: the fix is almost never clever. It's mechanical, and the goal is to make parameterization the path of least resistance in your codebase — a shared data-access layer that makes concatenation awkward is worth more than any amount of training.