How to Find SQL Injections Guide

Mia found her first critical vulnerability by simply entering a single quote into a search bar and seeing a raw SQL error. In this tutorial, I will pull back the curtain on the exact methodology she used to find and security test SQL injections.

What is SQL Injection? The Impact and Mechanism

At its core, SQL Injection is a vulnerability often ranked at the top of the OWASP Top 10, where an security tester can interfere with the queries that an application makes to its database. It typically occurs when an application uses unvalidated user input directly in a SQL statement. By crafting specific inputs, an security tester can "break out" of the intended query and execute their own commands.

The impact can be catastrophic. An security tester can circumvent authentication, view sensitive data (like passwords and credit card numbers), or in some cases, gain administrative control over the entire database server. Modern applications should also look into API Security to prevent backend leaks through JSON-based injections.

The Three Flavors: Types of SQL Injection

Before you start testing, you need to understand what you're looking for. SQL injections are generally categorized into three groups:

In-band SQLi (Classic): The security tester uses the same communication channel to launch the scenario and gather results. This includes Error-based and Union-based techniques.
Inferential SQLi (Blind): The security tester doesn't see direct output. Instead, they observe changes in the application's response (e.g., page loading differently) or timing (e.g., the server taking 5 seconds to respond).
Out-of-band SQLi: The most rare and dangerous type. The security tester triggers a database action that makes a request to an external server they control (like a DNS or HTTP request).

Manual Testing Methodology: A Pro's Reconnaissance

I always start with manual testing. Scanners often miss subtle injections that require a human eye. Here is my step-by-step process:

Step 1: Identify "Interesting" Parameters

Look for any part of the application that interacts with a database. This includes search bars, login fields, profile settings, and even cookie values. Parameters like `?id=123`, `?category=books`, or `?order=desc` are prime targets.

Step 2: The Character Test

Input a single quote (`'`), a double quote (`"`), or a semicolon (`;`) into the parameter. If the application returns a database-specific error (like "You have an error in your SQL syntax"), you have found an entry point.

Step 3: Boolean Inference

Try sending a true and false condition. For example:

?id=1' AND 1=1-- (True - Should load normally)
?id=1' AND 1=2-- (False - Should show an error or empty page)

If the results differ, the application is vulnerable to Blind SQLi.

Finding SQLi with Burp Suite: Hands-on Practice

If you haven't yet, check out our Burp Suite Tutorial. It is the best way to handle these requests. Here is how I use Burp for SQLi:

Intercept & Repeater: Catch the request and send it to Repeater. This allows you to test different test cases without refreshing the browser constantly.
Union Testing: Use Repeater to find the number of columns being returned. Test Cases like `' ORDER BY 1--`, `' ORDER BY 2--`, etc., until the page errors out.
Data Extraction: Once the column count is found, use a UNION SELECT to display the database version: `' UNION SELECT 1,2,@@version--`.

Automated Scanning with SQLmap

While manual testing is key for discovery, SQLmap is the king of security testing. It automates the tedious part of extracting huge amounts of data. Here is a basic command I use frequently:

sqlmap -u "http://target.com/search.php?id=1" --batch --dbs

The `--batch` flag answers all prompts with defaults, and `--dbs` lists all the databases on the server. If the target requires a login, you can pass the cookies from Burp Suite using the `--cookie` flag.

Real-World Case Study: My Most Memorable Security Research

A few years ago, I was testing a large e-commerce platform. No SQLi was apparent in the main search bar. However, I noticed that when I added an item to the cart, the `CartID` cookie was a Base64-encoded string. After decoding it, I found it was a JSON object. I injected a single quote into the `itemID` field inside that JSON, re-encoded it, and got a SQL error. That "hidden" injection netted a $5,000 bounty.

Common Mistakes Beginners Make

When learning SQL injection, beginners often stumble on fundamental concepts that seem obvious in hindsight. Understanding these mistakes early prevents wasted time and solidifies your understanding.

Mistake #1: Not understanding input validation vs. parameterization. Many beginners believe that simple input validation (like checking if a string contains quotes) prevents SQL injection. It doesn't. Security Testers can circumvent basic filters using encoding techniques, Unicode escaping, or alternative test cases. The correct approach is parameterized queries (prepared statements), which separate code from data at the database level.

Mistake #2: Only testing GET parameters. Beginners often focus exclusively on URL parameters and ignore POST data, headers, cookies, and API endpoints. SQL injection vulnerabilities exist anywhere user input reaches a database query. Test login forms, search boxes, file uploads, and authentication tokens.

Mistake #3: Assuming modern frameworks are always safe. Frameworks like Django, Laravel, and Spring provide built-in protections, but misuse defeats them. String concatenation circumvents protections entirely. Even with frameworks, you must explicitly use parameterized queries.

Real-World Case Study: The Sony PSN Breach

In April 2011, security researchers executed a devastating SQL injection scenario on Sony's PlayStation Network (PSN), compromising approximately 77 million user accounts. This remains one of the largest data breaches in history.

Technical root cause: Sony failed to implement proper input sanitization and parameterized queries. User-supplied data was concatenated directly into database queries without validation. Security Testers crafted SQL injection test cases in login fields and API endpoints, gaining direct database access.

Impact: The breach cost Sony $171 million in direct costs, including identity theft insurance for customers, network security infrastructure upgrades, and massive reputational damage.

Essential Tools for SQL Injection Testing

SQLMap: Automates SQL injection detection and security testing. Supports multiple databases like MySQL, PostgreSQL, and Oracle.
Burp Suite Community: Provides manual request interception. Capture requests, modify test cases, and test different injection points.
DVWA (Damn Vulnerable Web Application): Intentionally vulnerable practice environment for learning scenario mechanics safely.

How to Prevent SQL Injections (For Developers)

Stopping SQLi is actually very straightforward, yet developers still get it wrong. The gold standard is Parameterized Queries (Prepared Statements). Here is a secure example in PHP:

 $stmt = $pdo->prepare('SELECT * FROM users WHERE email = :email');
 $stmt->execute(['email' => $user_input]);
 $user = $stmt->fetch();

By using placeholders (`:email`), the database engine treats the user input as a literal string, never as part of the SQL command logic.

Conclusion & Next Steps

Mastering this SQL injection tutorial takes practice. Start by practicing on legal, intentionally vulnerable platforms. Once you understand the feeling of "breaking" a query, you'll start seeing these vulnerabilities everywhere.

Immediate Practice:

Set up DVWA locally using Docker. Spend 4-5 hours on SQLi labs until you can manually extract data.
Study one real-world CVE involving SQL injection. Understand the vulnerability, security testing technique, and patch.
Master advanced techniques like Blind SQLi and WAF circumvent.