SQL Injection Explained: The Attack That Won't Die

A 20-Year-Old Vulnerability Still Dominating Breach Reports

In 2023, the MOVEit Transfer vulnerability (CVE-2023-34362) compromised over 2,600 organizations and exposed data on more than 77 million individuals. At its core, the exploit was a SQL injection. The Cl0p ransomware gang used it to steal data from federal agencies, major airlines, and financial institutions. That single flaw — a failure to sanitize user input before passing it to a database — caused billions of dollars in damage.

If you think SQL injection is a relic of the early 2000s, I need you to reconsider. It still appears in OWASP's Top 10 (now grouped under "Injection"), it still shows up in the Verizon Data Breach Investigations Report year after year, and it's still the first thing many threat actors try when probing a web application. This post is SQL injection explained from the ground up — how it works, why it persists, what real attacks look like, and exactly how to stop it.

SQL Injection Explained in Plain Language

What Is a SQL Injection Attack?

SQL injection (SQLi) is a code injection technique that exploits a vulnerability in an application's database layer. It happens when user-supplied input is inserted into a SQL query without proper validation or sanitization. The attacker doesn't need to break encryption or guess passwords. They just type malicious SQL commands into a form field, URL parameter, or API call — and the database obediently executes them.

Think of it this way: your application asks a database a question. A SQL injection attack lets the attacker rewrite that question. Instead of "show me this user's profile," the query becomes "show me every user's profile" — or worse, "delete everything."

A Simple Example That Shows the Danger

Imagine a login form. The application takes your username and password and builds a query like this:

SELECT * FROM users WHERE username = 'input_user' AND password = 'input_pass';

An attacker types this into the username field:

' OR '1'='1' --

The resulting query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' --' AND password = '';

The condition '1'='1' is always true. The double dash (--) comments out the rest of the query. The database returns every row in the users table. The attacker is now logged in, often as the first user in the database — which is frequently the administrator.

That's the terrifying simplicity of it. No special tools required. No sophisticated malware. Just a few characters in a text box.

Why SQL Injection Refuses to Die

I've been in this field long enough to watch SQL injection go from a novel attack to a "surely everyone patches for that by now" assumption. They don't. Here's why it persists in 2024:

Legacy code. Millions of applications were built before parameterized queries became standard practice. Those applications are still running. Many organizations don't even have the source code anymore.

Developer pressure. Speed-to-market beats security in most development shops. Developers under deadline pressure reach for string concatenation because it's faster to write. A single shortcut creates a vulnerability that lasts years.

Complexity of modern stacks. Today's applications involve APIs, microservices, third-party libraries, and multiple database engines. Each integration point is a potential injection surface. One overlooked endpoint is all it takes.

Automated scanning by threat actors. Attackers don't manually test every website. They use automated tools like sqlmap that crawl thousands of targets per hour. If your application has a SQLi vulnerability, it will be found — not in months, but in days.

Real Breaches Powered by SQL Injection

MOVEit Transfer (2023)

As I mentioned above, the Cl0p ransomware gang exploited a SQL injection vulnerability in Progress Software's MOVEit Transfer product. The breach hit organizations including the U.S. Department of Energy, Shell, British Airways, and hundreds of others. CISA issued an advisory urging immediate patching. The scope was staggering — one SQLi flaw, thousands of victims.

Heartland Payment Systems (2008)

SQL injection gave attackers initial access to Heartland's network, eventually leading to the theft of 130 million credit card numbers. It was one of the largest data breaches in history at the time. Heartland paid over $110 million in settlements.

TalkTalk (2015)

A teenager exploited a SQL injection vulnerability in the UK telecom company TalkTalk, exposing personal data of nearly 157,000 customers. The company was fined £400,000 by the UK's Information Commissioner's Office — not because the attack was sophisticated, but because TalkTalk failed to implement basic protections against a well-known vulnerability.

These aren't edge cases. They're what happens when organizations treat SQL injection as a theoretical risk instead of an active, ongoing threat.

The Five Types of SQL Injection You Need to Know

1. In-Band (Classic) SQLi

The most common type. The attacker sends malicious SQL through the same channel used to collect results. This includes error-based SQLi (using database error messages to extract information) and UNION-based SQLi (using UNION statements to combine results from multiple queries).

The application doesn't display database errors or query results directly. The attacker asks true/false questions and observes the application's behavior. Boolean-based blind SQLi checks whether the page renders differently based on the injected condition. Time-based blind SQLi injects commands like WAITFOR DELAY and measures response times.

3. Out-of-Band SQLi

The attacker triggers the database to send data to an external server they control — often via DNS or HTTP requests. This works when in-band techniques are unreliable but the database server can make outbound connections.

4. Second-Order SQLi

The malicious input is stored in the database and executed later when a different function retrieves it. This is harder to detect because the injection point and the execution point are separated in time and code.

5. Stored Procedure Injection

If an application calls stored procedures with unsanitized input, attackers can inject SQL into the procedure call. This is particularly dangerous because stored procedures often run with elevated privileges.

How to Defend Against SQL Injection — Practical Steps

Use Parameterized Queries (Prepared Statements)

This is the single most effective defense. Parameterized queries separate SQL code from data. The database engine knows exactly which parts are commands and which parts are user input. It's impossible for injected SQL to be executed as code.

Every major programming language and framework supports this: PDO in PHP, PreparedStatement in Java, parameterized queries in Python's psycopg2, and Entity Framework in .NET. There is no excuse to use string concatenation in database queries in 2024.

Validate and Sanitize All Input

Never trust user input. Period. Apply allowlists (not denylists) to define what characters and patterns are acceptable. If a field expects a zip code, reject anything that isn't five digits. Input validation won't stop all SQLi by itself, but it's a critical layer.

Deploy a Web Application Firewall (WAF)

A WAF inspects incoming HTTP requests and blocks known attack patterns. It's not a substitute for secure code, but it buys time against automated attacks and zero-day exploits. CISA recommends WAFs as part of a defense-in-depth strategy.

Apply the Principle of Least Privilege

Your application's database account should have the minimum permissions needed to function. If it only needs to read from three tables, don't give it write access to the entire database. If an attacker does achieve injection, least privilege limits the blast radius.

Keep Software Updated

The MOVEit breach was devastating because organizations delayed patching. When a vendor releases a security update, apply it immediately. Track CVEs through the NIST National Vulnerability Database and prioritize patches for internet-facing applications.

Conduct Regular Penetration Testing

Automated scanners catch low-hanging fruit. Skilled penetration testers find second-order injection, logic flaws, and blind SQLi that scanners miss. Test at least annually, and after any major code release.

Implement Multi-Factor Authentication

Even if a SQL injection attack lets an attacker bypass a login form, multi-factor authentication adds another barrier. It won't prevent the injection itself, but it limits what credential theft achieves.

Here's something I don't see discussed enough: SQL injection attacks are often combined with social engineering. A threat actor might use phishing to compromise a developer's credentials, then access source code repositories to find injectable endpoints. Or they use SQLi to extract employee email addresses, then launch targeted phishing campaigns against those employees.

This is why security awareness training matters even for technical vulnerabilities. Your developers need to understand secure coding. Your entire staff needs to recognize phishing simulation scenarios and real attacks. The technical and human layers of defense are inseparable.

If you're building a security awareness program, our cybersecurity awareness training course covers the intersection of social engineering and technical attacks. For organizations specifically focused on the human element, our phishing awareness training for organizations delivers hands-on scenarios that prepare employees for real-world credential theft attempts.

How Do You Know If You're Vulnerable Right Now?

Start with these questions:

Do any of your applications use string concatenation to build SQL queries?
When was the last time a penetration tester specifically assessed your web applications for injection flaws?
Are your developers trained on OWASP Top 10 vulnerabilities, including injection?
Do you have a WAF in front of your internet-facing applications?
Are your database accounts configured with least privilege?
Have you inventoried all third-party software and confirmed patches are current?

If you answered "no" or "I don't know" to any of these, you have work to do. SQL injection isn't a risk you can accept and forget. It's an active threat that automated tools probe for constantly.

SQL Injection in a Zero Trust World

Zero trust architecture assumes no user, device, or application is inherently trusted. Applied to SQL injection defense, this means:

Don't trust the application layer. Even internal applications should use parameterized queries. Lateral movement after a breach means internal apps become attack surfaces too.

Don't trust the network perimeter. WAFs help, but they can be bypassed. Secure code is the actual fix. Defense in depth means layering WAFs, input validation, parameterized queries, and least privilege together.

Don't trust the user. Every input — from a customer, an employee, an API partner, or a microservice — should be treated as potentially hostile. This isn't paranoia. It's engineering discipline.

The Cost of Getting This Wrong

According to IBM's 2024 Cost of a Data Breach Report, the global average cost of a data breach reached $4.88 million. Breaches involving stolen credentials — which SQL injection frequently enables — took an average of 292 days to identify and contain. That's nearly ten months of undetected data exfiltration.

For small and mid-sized businesses, a single SQL injection breach can mean regulatory fines, customer lawsuits, lost revenue, and reputational damage that takes years to recover from. The FTC has taken enforcement action against companies that failed to protect against well-known vulnerabilities. "We didn't know" is not a defense when the vulnerability has been documented for over two decades.

Your Next Steps

SQL injection explained in a blog post gives you the knowledge. What you do with it determines whether your organization becomes the next case study or the one that stopped the attack.

Audit your code. Patch your software. Train your developers. Deploy defense in depth. And invest in security awareness training that connects technical vulnerabilities to human behavior — because the next SQL injection attack on your organization might start with a phishing email to a developer.

The vulnerability is old. The attacks are current. Your defenses should be too.