We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 5-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
In 2008, Heartland Payment Systems suffered a injection attack that exposed 134 million credit card numbers. The attacker found a single unprotected search endpoint, injected SQL code, and extracted the entire payment card database over several months. The breach cost Heartland $140 million in settlements.
That was 2008. You might think we have moved past this. We have not. In 2023, MOVEit Transfer had a SQL injection vulnerability (CVE-2023-34362) that compromised over 2,600 organizations including the BBC, Shell, and the US Department of Energy. Cl0p ransomware group exploited it for mass data theft.
SQL injection works by inserting malicious SQL into a query that uses string concatenation:
// VULNERABLE:
query = "SELECT * FROM users WHERE email = '" + userInput + "'"
// If userInput is: ' OR '1'='1
// The query becomes:
// SELECT * FROM users WHERE email = '' OR '1'='1'
// This returns ALL users
The root cause is always the same: the database cannot distinguish between the SQL code you wrote and the SQL code the attacker injected, because you combined them into one string. The fix is equally simple: never concatenate user input into SQL. Use parameterized queries. No exceptions. No edge cases. No "but this input is validated."
OWASP ranked injection as the #1 web vulnerability for over a decade. It dropped to #3 in 2021 only because frameworks now parameterize by default. But every time a developer writes raw SQL with string concatenation for a "quick fix" or a "complex query," they reopen this exact vulnerability.
Not all injection looks the same. Attackers have four distinct techniques, each exploiting a different information channel. Tools like sqlmap automate all four and can detect which technique works in seconds.
Union-based injection is the fastest method. The attacker appends a UNION SELECT to the original query, merging their own query results into the page output. If your search page shows product names, the attacker's UNION query makes it show usernames and password hashes instead. This requires the page to display query results, and the attacker must match the column count of the original query (found by trying ORDER BY 1, ORDER BY 2 until an error appears).
Error-based injection extracts data through SQL error messages. Functions like CONVERT() or EXTRACTVALUE() throw errors that include evaluated values. If the error message says "cannot convert 'users' to int," the attacker just learned a table name. This is why production applications must never expose raw SQL errors to the client.
Blind boolean injection works when the page shows no data and no errors. The attacker asks true/false questions: "Is the first character of the admin password 'a'?" Different page content (or different response sizes) reveals the answer. Each character takes about 50 requests to determine through binary search. A 32-character hash requires roughly 1,600 requests. Automated tools finish this in minutes.
Time-based blind injection is the last resort. The attacker injects SLEEP(5). If the response is delayed by 5 seconds, the condition was true. This works even when the page is completely identical for all inputs. It is the slowest technique but nearly undetectable at the application level.