21 Лют, 2024

Blind SQL injection

Blind SQL injection is a type of attack on web applications in which an attacker can extract information from a database without receiving explicit error messages. This is done by sending SQL queries to a web application that cause the application to behave differently depending on whether the conditions in those queries are true or false. For example, if the query results in a valid condition, the web page may load as normal, but if the condition is incorrect, it may take longer to load or the page may behave differently.

An attacker can construct logical queries that gradually reveal data, for example, by checking each character of a value in the database one at a time. This requires patience and multiple queries, but allows information to be extracted even if direct data output (as in the case of classic SQL injection) is not possible. Thus, Blind SQL Injection is a more stealthy attack method that can be successful even where standard SQL injection prevention methods have already been applied.

Приклади експлуатації

To deepen knowledge of Blind SQL Injection, a hands-on exercise from PortSwigger, which is an authority on web security, is offered. This exercise focuses on the Blind SQL Injection vulnerability found in the cookie tracking mechanism used for analytics. The vulnerability allows the execution of SQL queries that depend on the value of the passed cookie.

The goal of this lab is to use Blind SQL Injection to extract data from various database tables. To do this, you must execute a series of queries that will cause the application’s responses to change depending on the correctness of the conditions entered in those queries, since direct query results are not returned and error messages are not displayed.

To successfully complete the lab work, we need to manipulate the queries in such a way that we can figure out the administrator user’s password by exploiting the differences in the application responses.

Let’s start by examining a cookie tracking request on a website.

As we can see the cookie uses 2 components, ‘TrackingId’ and ‘session’. Let’s focus on TrackingId and try to change the data in it. We know that when TrackingId is valid, it returns a “Welcome back!” message, otherwise we will not get this message. Let’s consider these situations.

Now add the number 1 to this id, for example.

Okay, now let’s determine if cookies are vulnerable to SQL injection. Let’s use this payload ‘ and 1=1’–. This payload says “If cookie = true = Welcome back!”

Let’s now change our payload into this format ‘ and 1=0–. Now the format of the payload is ‘If Cookie = True = Don’t send message’

Now let’s find out if the “users” table exists. To do this, we will use this payload ‘ and (SELECT ‘a’ from users LIMIT 1) = ‘a’ —. This payload says “if cookie = a (Which is a subquery, and selects a row with one character 'a ‘ from the users table (LIMIT 1 restricts the output to only one row)) = a = Welcome back! “. So we get a positive result if the table exists. 

Now we need to see if the administrator user exists in the users table. To do this, we will use this payload ‘ and (SELECT username from users where username=’administrator’)=’administrator’–. It tells the database “If cookie = administrator (Which in turn is selected from the username row in the users table) = administrator = Welcome back!”.

Okay, the user has been found. Now use a payload like ‘ and (select username from users where username=’administrator’ and LENGTH(password)>1)=’administrator’– to understand the password length. I will use intruder to bruteforce the password length.

(Now we realise that the password contains 19 characters.)

Now we can start bruteforcing the password. We will search each character of the password, then move to the next and so on until we reach 19 characters using Cluster Boomb in burp. To do this we will use the substring command which will help us with this. Here’s a payload that we’ll put in the intruder ‘ and (select substring(password,1,1) from users where username=’administrator’)=’a’–.

Scanners that detect vulnerabilities

  1. SQLmap: An open-source Пентест tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It has a powerful detection engine and offers a wide range of features for pen-testing.

  2. Acunetix: A fully automated web vulnerability scanner that detects and reports on over 4500 web application vulnerabilities including all variants of SQL Injection. It’s known for its speed and accuracy.

  3. OWASP ZAP (Zed Attack Proxy): An open-source web application security scanner. It helps you automatically find security vulnerabilities in your web applications while you are developing and testing applications.

  4. Burp Suite Scanner: Part of the Burp Suite of tools, this scanner is a leading software for web SECURITY TESTING. It’s an integrated platform for performing security testing of web applications and includes a scanner that can detect SQL injection vulnerabilities.

  5. Netsparker: An easy-to-use web application security scanner that uses the advanced Proof-Based Scanning™ technology to identify SQL Injection and other vulnerabilities in web applications and web services.

  6. IBM Security AppScan: This tool provides automated vulnerability scanning for web applications. It includes comprehensive scanning for a variety of vulnerabilities including Blind SQL injection.

  7. Veracode: Offers automated static and dynamic analysis to identify and remediate software vulnerabilities. It includes testing for SQL injection vulnerabilities.

  8. Qualys Web Application Scanning: A cloud-based service that automates crawling and testing of custom web applications to identify vulnerabilities. It can detect Blind SQL injection among other security issues.

Average CVSS score for Blind SQL injection

The average CVSS score for vulnerabilities related to SQL injections, including Blind SQL injection, typically ranges between 7 and 9, indicating a high severity level. This high-severity classification reflects the potential significant impact these vulnerabilities can have on system security, such as unauthorized access to or manipulation of database content, disruption of service, or data leakage. The scoring can fluctuate based on various factors, including the complexity of the attack, the level of access that could be obtained, and the potential consequences for the affected system.

For instance, an advisory by Invicti listed a Blind SQL Injection vulnerability in Geeklog with a CVSS score of 8.6, denoting a high level of severity. Similarly, a report by Tenable on the Delta Electronics DIAEnergie vulnerability indicated a CVSS v3 base score of 9.8, which is also categorized as critical severity.

These scores emphasize the critical nature of Blind SQL Injection vulnerabilities and the importance of securing web applications against them. Regular testing, code review, input validation, and the implementation of parameterized queries are essential practices to mitigate the risks associated with these types of security flaws.

CVES related to Blind SQL injection

CVE-2023-28883: A blind SQL injection vulnerability was found in Cerebrate 1.13, within the searchAll API endpoint.

CVE-2020-13921: This vulnerability was present in Apache SkyWalking when using certain databases for storage, allowing for SQL injection via wildcard query cases.

CVE-2022-26013: Identified in Delta Electronics DIAEnergie, this vulnerability could allow an attacker to perform blind SQL injection.

CVE-2021-12345: (Hypothetical) This would represent a generic identifier for a blind SQL injection vulnerability that has been documented in the CVE system.

CVE-2021-54321: (Hypothetical) Another placeholder for a known blind SQL injection vulnerability, each unique CVE ID corresponds to a specific security issue.

To study Blind SQL injection

  1. Start with the principles of SQL, SQL Injection, and how databases work. Knowing how SQL queries are structured and executed is crucial.

  2. There are many tutorials online that explain Blind SQL Injection step-by-step. Look for hands-on examples that you can practice.

  3. Platforms like PortSwigger Web Security Academy offer labs where you can practice Blind SQL Injection in a safe, legal environment.

  4. There are comprehensive books on web application security  that cover various types of SQL Injection attacks in depth.

  5. Capture The Flag (CTF) competitions often have challenges related to SQL Injection that can test your skills.

  6. Engage with cybersecurity communities. Forums and groups can be a valuable resource for learning from experienced professionals.

  7. Follow CVE databases and security advisories to learn about real-world vulnerabilities and understand how they were exploited.

How to be protected from Blind SQL injection

  1. Use parameterized queries (also known as prepared statements) which ensure that SQL query execution happens using parameters, instead of embedding user input in the query.

  2. Encapsulate your SQL queries within stored procedures in the database, which can reduce the surface area for injection.

  3. Utilize Object-Relational Mapping (ORM) libraries which typically handle data sanitization and provide another layer of abstraction over raw SQL queries.

  4. Rigorously validate user inputs to ensure they conform to expected formats. This won’t protect against SQL injection alone but can reduce the risk.

  5. If for some reason you can’t use parameterized queries, make sure to escape user input using the appropriate SQL escaping function for your database.

  6. Ensure that the database account used by the application has the least privilege necessary. Do not use an account with admin or root-level access.

  7. Implement a WAF that can filter out malicious data.

  8. Keep your database management system (DBMS) and all related applications up to date with patches and security updates.

  9. Customize error messages to prevent the application from outputting database error messages to the user.


In the conclusion of our article on Blind SQL Injection, we emphasise the seriousness and complexity of this type of attack on web applications. Blind SQL Injection differs from traditional SQL injections in that the attacker is not provided with explicit error messages from the database, requiring them to use subtle and indirect methods to extract data. This makes detecting and preventing such attacks more difficult, but no less critical to data security.

Recognising the real threat posed by such attacks, we emphasise the importance of a comprehensive approach to web application security. Database developers and administrators need to implement protection strategies such as the use of parameterised queries, ORM (Object-Relational Mapping), strict input validation and regular software updates to minimise the risks and vulnerabilities that can be exploited through Blind SQL Injection.

Інші Послуги

Готові до безпеки?

зв'язатися з нами