Six real incidents across two decades. The payloads, the root causes, the post-mortems. The pattern they share is the same as lesson 1: a string-concat query that was never meant to be string-concat. What changes between them is the technique used to extract the data - and the cost of not having fixed the bug earlier.
- L4Authentication bypass
- L6UNION-based extraction
- L8Blind injection overview
- L13Finding it in the wild
- L17WAF & detection
- Map a real incident to the technique, the root cause, and the cost.
- Recognise the long-tail risk of unmaintained legacy endpoints.
- Explain why the bug persists across industries and decades.
- Use the case studies as a template for writing your own post-mortem.
- Post-mortem
- A document an organisation writes after a security incident. The best post-mortems name the root cause, the technique, and the systemic fix. The SQLi case studies are a textbook of what good (and bad) post-mortems look like.
- Legacy endpoint
- An endpoint that was retired from the main product but kept alive for back-compat. Heartbleed and the 7-Eleven breach both involved legacy code that was never updated.
- Centralised platform
- A piece of software that serves many customers. A single SQLi in a centralised platform compromises every customer. The 7-Eleven / CBS breach is the canonical example.
- SSO trust path
- The chain of authentication that grants a session. A SQLi anywhere in the chain (even in a legacy endpoint) is SQLi in production.
Six incidents, one pattern
Every SQLi breach in the public record shares the same fundamental flaw: a string-concat query in a piece of code that someone wrote believing the input was safe. The attacker's technique varies; the bug does not.
The attacker exploited a string-concat bug in a web-facing endpoint, used UNION SELECT to enumerate the schema, and exfiltrated the track data of every card the processor handled. The post-mortem named the root cause as "a SQL injection vulnerability" in a 2007-era ASP application. The case drove widespread adoption of parameterised queries in the payment industry.
SQL injection in a payment-processing web application; string-concatenated queries against an unpatched database.
Largest card breach in US history at the time. ~$140m in fines and settlements.
What these incidents share
Three patterns are common to every case above. First, the bug was reported or discoverable before the breach - TalkTalk had a researcher report on file; HBGary's CMS was running a known-vulnerable version of an off-the-shelf product; the Fortnite legacy endpoint was a 2004-era stats page that nobody owned. The fix was technically possible years before the breach. Second, the root cause was almost always a string-concat query in a single endpoint, not a systemic pattern across the codebase. The fix is one file, not a rewrite. Third, the cost of the breach was orders of magnitude larger than the cost of the fix. Heartland's $140m in fines is a 70,000x return on a parameterised query.
The fix is always the same
// VULNERABLE - string concatenation
const query = "SELECT * FROM users WHERE id = '" + id + "'";
// SAFE - parameterised
const query = 'SELECT * FROM users WHERE id = $1';
const result = await db.query(query, [id]);The repetition is the point. The fix does not depend on the attacker's technique, the database engine, the framework, or the language. It is one line: replace the string-concat with a bound parameter. The post-mortem for every one of the incidents above would have been a single line long.
What to remember
- Every SQLi breach in the public record is a string-concat query. The technique varies; the bug does not.
- Legacy endpoints and centralised platforms are the highest-impact attack surfaces.
- The cost of a parameterised query is one line. The cost of not having it is a breach disclosure.
- A good post-mortem names the root cause, the technique, and the systemic fix - not just the patch.
Knowledge check
0/3 answered · 0 correct1.What is the common pattern across the Heartland, HBGary, TalkTalk, 7-Eleven, Fortnite, and Cloudflare cases?
2.Why is a SQLi in a centralised platform (like the 7-Eleven / CBS payment platform) more damaging than a SQLi in a single application?
3.What is the cost-benefit of fixing a SQLi?