Injection flaws allow adversaries to inject untrusted data into a system or application through a malicious query/command. The malicious code is typically used to compromise both the application’s clients and backend systems. This article explains a Blind SQL Injection flaw, various types of attacks, and best practices to prevent them.
Don’t have time to read? Listen to this blog post instead.
What is SQL Injection?
The SQL injection (SQLi) vulnerability enables attackers to send malicious input to an application by modifying database queries. By exploiting SQLi flaws, hackers can manipulate the application’s backend using malicious statements that control its database server. Therefore, the hackers can access all the database contents or bypass application security checks using SQL injection vulnerabilities. Adversaries can also use dangerous SQL queries to delete, modify or add remote database records, thus impacting the credibility of data processed by the vulnerable web application.
The hacker must scan the application for user input interfaces vulnerable to injection to perform an SQL injection attack. They then create a malicious payload using SQL statements to be executed by the application’s database. Besides accessing data tables and user credentials, attackers can craft malicious SQL queries to access the OS using the database server. SQL injection is one of the oldest, most prevalent, and most dangerous web vulnerabilities. It affects any application or website that relies on a relational SQL database, such as the SQL server.
SQL injection attacks can be of several types. These include:
1. In-band SQLi attacks
2. Out-of-band SQLi attacks
3. Blind SQLi attacks
Blind SQLi Explained
This is a type of SQLi injection attack in which the adversary sends malicious queries to the server then uses its response to make inferences about the application’s configuration. Blind SQLi attacks are mainly performed on websites vulnerable to SQL injection and show generic information for each error message. This type of attack is known as Blind/Inferential SQLi. The server does not output the queried data on the attacker’s web interface, so they employ a series of follow-up queries to infer its response and behavioral patterns. Since the HTTP response of the database server typically lacks details of database errors or relevant SQL query results, blind SQLi attacks are challenging to perform but possible.
Blind SQLi attacks are primarily categorized into:
1. Boolean/content-based blind SQL injection attacks
This type of Blind SQLi attack involves testing the database server for vulnerabilities by crafting queries that ask the database TRUE or FALSE objective-type questions. An attacker then checks whether each query modifies the information within the HTTP response to make inferences about the database schema and server’s configuration.
2. Time-based SQL injection attacks
In a time-based attack, hackers craft an SQL command that forces the server to wait a certain period before responding. They send this database query to the server then observe how long it takes to respond. Depending on whether the response was sent instantly or after a while, the hacker will determine whether the malicious queries were TRUE or FALSE statements without relying on any data sent by the server. This type of attack involves a time-intensive operation as each database entry has to be enumerated character by character.
How to Prevent Blind Injection Attacks and its Importance in Security
Any application with SQL injection vulnerabilities is susceptible to blind SQL injection attacks. This section describes how to protect Blind SQL injection attacks in modern websites and web applications.
Blind SQL Injection Prevention – Best Practices
Parameterize SQL statements
A parameterized query is a premade SQL statement such that the user only needs to supply values/parameters into the statement for the database to execute it. Developers should parameterize all dynamic query user input, enabling strict and robust controls on which queries the database should run. Besides preventing injection attacks, parameterized queries (prepared statements) allow the database to execute the same statement multiple times without compiling, parsing, or optimizing again. This improves the database server response times, improving application efficiency.
Utilize secure coding practices
Use your chosen web platform’s inbuilt injection prevention mechanisms to protect the application against Blind SQLi attacks. The OWASP SQL injection cheat sheet includes multiple prevention and mitigation measures for Blind SQLi flaws. Developers should ensure proper input validation at query input locations. Additionally, in Database systems that support stored procedures, developers can use them to define expected queries, avoiding malicious user-controllable inputs. Filtering and escaping special characters for all database inputs ensures the server only executes allowed queries. An often-overlooked best practice is avoiding generic error messages, which may provide information for the hacker’s arbitrary code.
Use an automated vulnerability scanner.
An automatic vulnerability scanner helps cross-functional teams identify injection gaps within a web application before hackers can exploit them through continuous, autonomous testing. The Crashtest Security Suite includes a vulnerability scanner that scans single and multi-page web applications and APIs to eliminate security blind spots with few false positives and negatives. The scanner continuously benchmark’s the website’s security posture against the OWASP top 10, allowing security teams to detect and remediate injection flaws as they emerge throughout the SDLC.
Why is it Important for Your Business?
It is vital to prevent Blind SQLi vulnerabilities as they grant attackers access to a vulnerable application’s database, which can have significant consequences. These include:
1. Theft of sensitive client data such as credit card details and other Personally-Identifying Information (PII)
2. Executing administrative commands through database manipulation
3. Application unavailability due to modified or missing underlying database records
4. Database fingerprinting allows the attacker to identify the recipients of data
Blind SQL Injection Example
Some common examples of Blind SQLi attacks include:
Password Enumeration Using Time-based Blind SQL injection
Time-based attacks are highly dependent on the type of database being accessed. With such attacks, attackers can craft a statement that enumerates user passwords using logic similar to:
If the first letter is an ‘A’, wait 10 seconds
If the first letter is a ‘B’, wait 15 seconds…and so on.
The attacker may use a SQL query such as:
SELECT IF(expression, true, false)Combined with a time-taking operation such as BENCHMARK() that delays the database’s response if the expression is true. The hacker ensures that the BENCHMARK operation specifies enough function repetitions to give the server a noticeable delay in response. A 5-second delay can be achieved by executing the function 5000000 times, as shown:
BENCHMARK(5000000,ENCODE('MSG','by 5 seconds'))The attacker then combines both queries:
1 UNION SELECT IF(SUBSTRING(user_password,1,1) = CHAR(50),BENCHMARK(5000000,ENCODE('MSG','by 5 seconds')),null) FROM users WHERE user_id = 1;If there is a delay in database response time, then user-id1’s first password character is a 2:
(CHAR(50) == '2')Attackers can use this method for the rest of the characters to enumerate all passwords in a database, compromising their accounts.
Content-based Attacks
Hackers commonly use Boolean attacks to uncover SQLi vulnerabilities in an application. Assuming an e-Commerce website displays items for sale retrieved from a database server with the URL:
http://www.darwin.com/item.php?id=05Where the SQL query used to access the resource and column names is:
SELECT columnName, columnName2 FROM table-name WHERE id = 05An attacker can supply the following malicious query to exploit the SQLi vulnerability:
http://www.darwin.com/item.php?id=05 and 1=2This modifies the query to look like this:
SELECT columnName2 FROM tableName WHERE ID = 14 and 1=2SELECT If this returns a FALSE response with the list displaying no items, the attacker modifies the payload to:
http://www.darwin.com/item.php?id=05 and 1=1In this case, the SQL query will look similar to:
SELECT columnName, columnName2 FROM tableName WHERE ID = 05 and 1=1As the query returns the TRUE value, the database displays the details of item 05 in its response.
FAQs
Differences: Blind SQL injection VS SQL injection
SQL injection attacks are broad and can be categorized as blind, in-band, and out-of-band SQLi attacks. In Blind SQLi attacks, the hacker does not access the data exposed in-band since the data is not sent to the attacker from the database. Blind SQLi attacks are typically slower than generic SQL injection attacks since the exploitation relies on the database server’s behavioral and response patterns.
Is the UNION attack a Blind SQL attack?
Hackers can use the UNION attack to extend the results of an initial query and extract information from a database error. In blind SQL attacks, on the other hand, hackers usually use the UNION operator to combine malicious payloads with legitimate queries that have the same structure.
This article has already been published on https://crashtest-security.com/blind-sql-injection/ and has been authorized by Crashtest Security for a republish.
Featured Image Courtesy – Photo by Boitumelo Phetla on Unsplash
