Claude on Question 19, Sep 12

SQL Injection: A Developer Briefing

SQL injection occurs when untrusted input is concatenated into a query such that it changes the query's structure rather than being treated purely as data. The classes below are usually organized by how an attacker extracts information, but it's also worth understanding injection contexts, since those determine whether a given defense actually works.

1. Classification by Data Retrieval Method

In-band (results come back through the same channel)

Union-based — The attacker appends a UNION SELECT to graft a second result set onto the original query's output. Requires matching column count and compatible types, which attackers determine by iterating. Highly efficient once working: entire tables can be dumped in a handful of requests.

Error-based — The application leaks database error messages, and the attacker crafts input that forces the DBMS to embed data inside the error text. Classic vectors include type-conversion errors (casting a subquery result to an integer), XML functions like EXTRACTVALUE/XMLType, and duplicate-key errors. Verbose errors alone aren't the vulnerability, but they dramatically accelerate exploitation.

Inferential / "Blind" (no data returned directly)

Boolean-based — The attacker injects a condition and observes whether the page content changes between true and false states. Data is extracted one bit or character at a time via substring comparisons. Slow but entirely reliable.

Time-based — Used when the response is identical regardless of query outcome. The attacker conditionally triggers a delay (SLEEP, pg_sleep, WAITFOR DELAY, or heavy computation like BENCHMARK) and measures response time. Works even against endpoints that return a fixed status code and empty body.

Out-of-band

The attacker forces the database to initiate an outbound connection — DNS lookup, HTTP request, SMB path resolution, or file write — carrying the exfiltrated data. Examples include xp_dirtree on SQL Server, UTL_HTTP/DBMS_LDAP on Oracle, and LOAD_FILE against a UNC path on MySQL. This class matters because it defeats defenses that rely on suppressing response differences, and it's often the only path when the injection is asynchronous.

Second-order (stored)

Input is safely stored, then later retrieved and unsafely concatenated into a different query. The vulnerable sink is far from the entry point, so input-validation-at-the-boundary thinking misses it entirely. Common example: a username containing a quote is stored via a parameterized insert, then interpolated into a dynamic query by a batch job or admin page. Emphasize this one to your team — it's the most common reason "we sanitize on input" fails.

2. Classification by Injection Context

This matters because each context has a different correct defense.

The key point: parameterized queries protect values, not structure. Any query where the attacker influences identifiers or clauses needs an allowlist, and that's where most residual injection bugs live in otherwise-modern codebases.

3. Related Variants Worth Naming

• •Stacked queries — A single request executes multiple statements separated by ;. Availability depends on the driver and DBMS; MySQL's default PHP driver historically blocked it, while SQL Server and PostgreSQL often permit it. Enables INSERT/UPDATE/DROP, not just reads.
• •ORM injection — ORMs are not inherently safe. Raw-query escape hatches (session.execute(), .raw(), whereRaw(), HQL/JPQL string concatenation) reintroduce the full problem. Audit every raw-query call site.
• •NoSQL injection — Structurally analogous but exploits operator injection (e.g., submitting {"$ne": null} or {"$gt": ""} where a string is expected) or server-side JavaScript evaluation. Worth covering if you run MongoDB or similar.
• •Encoding and filter bypasses — Multi-byte charset tricks, double-URL-encoding, comment insertion, and case variation defeat blocklists. Mention only to justify why blocklists are not a control.

4. What to Tell Developers to Do

Primary control — parameterized queries / prepared statements. Non-negotiable default for all value interpolation. Make this the reviewable standard.

Secondary — allowlists for structural elements. Map user-facing sort keys to hardcoded column names via a dictionary; never pass the user's string through.

Defense in depth:

• •Least-privilege database accounts; separate read-only credentials for reporting paths. No application account should hold DDL or FILE privileges.
• •Generic error pages in production; log details server-side only.
• •Egress filtering from database hosts to blunt out-of-band exfiltration.
• •Input validation as a complement, never a substitute — validate type, length, and format because it's good hygiene, not because it stops injection.

Explicit anti-patterns to reject in code review:

• •Manual quote-escaping or addslashes-style functions
• •Blocklists of keywords like UNION or SELECT
• •Stored procedures assumed safe — dynamic SQL inside a procedure (EXEC(@sql)) is just as vulnerable
• •Any string formatting into SQL, including f-strings and template literals

Verification: grep for string concatenation adjacent to query execution, add a lint or CI rule for raw-query calls, and cover the second-order paths in testing since scanners frequently miss them.

If it's useful, I can turn this into slides, write language-specific do/don't code samples for your stack, or draft a code-review checklist your team can apply directly.