SQL Injection Deep Dive

SQL injection exists because of one fundamental design flaw: string concatenation into a query. When you build a SQL statement by gluing user input directly into the query string, the database has no way to tell your data apart from your code. The attacker's input stops being a value and starts being an instruction.

The Root Cause: Data Becoming Code

Consider this classic vulnerable query:

query = "SELECT * FROM users WHERE username = '" + user_input + "' AND password = '" + password + "'"

When user_input is admin' --, the query becomes:

SELECT * FROM users WHERE username = 'admin' --' AND password = ''

The -- comments out the rest of the query. The password check vanishes. You're in. The even more famous payload, ' OR '1'='1, turns any WHERE clause into one that always evaluates to true, returning every row in the table.

This isn't a bug in SQL. It's a bug in how the application constructs queries. The database parser sees one continuous string of SQL and interprets it faithfully.

Types of SQL Injection

Not all SQL injection looks the same. The differences matter because they determine what the attacker can extract and how fast.

In-band (Classic). The attacker gets results directly in the application's response. Union-based injection appends a UNION SELECT to pull data from other tables — usernames, password hashes, credit card numbers — right into the page. Error-based injection extracts data through database error messages that leak table names, column names, and values.

Blind Boolean-based. The application doesn't display query results or errors, but the attacker can still ask true/false questions. By injecting conditions like AND SUBSTRING(password,1,1)='a' and observing whether the page behaves differently, they extract data one character at a time. Slow, but automatable.

Blind Time-based. When even boolean differences aren't visible, the attacker injects AND SLEEP(5). If the response takes 5 seconds, the condition was true. Same character-by-character extraction, just using timing as the side channel.

Out-of-band. On certain database configurations, the attacker can make the database itself send data to an external server via DNS lookups or HTTP requests. Less common, but it bypasses all response-based detection.

Beyond Auth Bypass: What Real Attackers Do

Logging in as admin is just the beginning. Once an attacker confirms SQL injection exists, the damage potential is enormous.

Dumping tables via UNION. By enumerating table names from information_schema, the attacker maps the entire database and extracts every table systematically. Usernames, hashed passwords, payment details, personal data — all of it.

Reading files from the server. MySQL's LOAD_FILE('/etc/passwd') reads local files. PostgreSQL has pg_read_file(). If the database user has file read permissions, the attacker can read application source code, configuration files with database credentials, and private keys.

Writing webshells. MySQL's INTO OUTFILE can write files to disk. If the database can write to a web-accessible directory, the attacker drops a PHP/JSP shell and has full remote code execution on the server.

OS command execution. SQL Server's xp_cmdshell runs operating system commands directly. A single SQL injection in a .NET app talking to SQL Server can lead to full server compromise in one step.

The Fix: Parameterized Queries

The only correct fix is parameterized queries (also called prepared statements). The concept is simple: separate the query structure from the data.

# Vulnerable
cursor.execute("SELECT * FROM users WHERE id = " + user_id)

# Fixed
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

With parameterized queries, the database compiles the query plan first, then binds the data into the parameter slots. The data can never be interpreted as SQL code because the parsing step is already complete. This isn't sanitization or escaping — it's a fundamentally different execution model.

Every modern language and database driver supports this. There is no performance penalty. There is no excuse not to use it.

ORMs Help, But Watch the Escape Hatches

ORMs like SQLAlchemy, ActiveRecord, and Hibernate use parameterized queries under the hood. When you write User.objects.filter(username=input) in Django, the ORM handles parameterization correctly.

The danger is raw query escape hatches. Every ORM provides them — Model.raw(), execute(), find_by_sql(). The moment a developer drops into raw SQL with string concatenation, they're back to square one. Code reviews should flag every raw query call and verify parameterization.

Why Input Sanitization Fails

Blocklists and input filtering seem intuitive but they don't work reliably. Attackers bypass them routinely:

• Encoding tricks: URL encoding, double encoding, Unicode normalization all produce payloads that slip through naive filters but are decoded before reaching the database.
• Comment injection: SEL/**/ECT bypasses keyword blocklists in many implementations.
• Case variation and concatenation: sElEcT, or CHAR(83)+CHAR(69)+CHAR(76)+CHAR(69)+CHAR(67)+CHAR(84) to spell out keywords without ever typing them.
• Context-dependent payloads: A filter designed for string context breaks when injection happens in a numeric context where no quotes are needed.

You cannot enumerate every possible attack string. Parameterized queries make the entire category of attacks structurally impossible.

Defense in Depth

Parameterized queries are the primary fix, but defense in depth means layering protections:

Least-privilege database user. Your application's DB account should have only the permissions it needs. No FILE privilege, no xp_cmdshell, no DROP TABLE. If injection somehow occurs, the blast radius is limited.

Web Application Firewall (WAF). A WAF can catch common injection patterns and buy you time. But it's a speed bump, not a wall. Every WAF has bypass techniques, and researchers publish new ones regularly. Never rely on a WAF as your primary defense.

Error messages that don't leak schema. Generic error pages in production. Never show raw database errors to users — they reveal table names, column names, database versions, and query structure. Log the details server-side; show the user "Something went wrong."

Principle of least information. Return only the columns and rows the user needs. Don't SELECT * when you need two fields.

Real-World Impact

SQL injection has been in the OWASP Top 10 since the list was created in 2003. It's still there decades later — not because we don't know the fix, but because the fix requires applying it everywhere and legacy code doesn't fix itself.

Tools like sqlmap automate the entire attack chain: detection, database fingerprinting, table enumeration, data extraction, file read/write, and OS shell. A single injectable parameter and a script kiddie with sqlmap can dump your entire database in minutes.

The Heartland Payment Systems breach (2008) exposed 130 million credit card numbers via SQL injection. In 2019, Fortnite had a SQL injection vulnerability that could have exposed 200 million user accounts. These aren't obscure targets — they had security teams and budgets.

Key Takeaways

• SQL injection happens when user input is concatenated into query strings, allowing data to be interpreted as code.
• Parameterized queries are the only reliable fix — they separate query structure from data at the parsing level.
• Beyond login bypass, attackers can dump entire databases, read server files, write webshells, and execute OS commands.
• ORMs protect you by default, but raw query escape hatches reintroduce the vulnerability instantly.
• Input sanitization and WAFs are unreliable as primary defenses — treat them as additional layers, not solutions.
• sqlmap automates the full attack chain, which means any injectable endpoint will be found and exploited.

Next up: XSS Attacks — same root cause as SQL injection, but the interpreter is the browser and the victim is another user.