Triggering Time Delays to Identify Blind SQL Injection Vulnerability

A SQL injection vulnerability is a serious security flaw that is found in insecure applications. This vulnerability occurs when developers do not sanitize user input for the application. Attackers can use input fields and other avenues of interaction with the database to inject malicious code into the server-side infrastructure. SQL code can be used to extract information from the application database, change information, and even delete information. The majority of SQL injection vulnerabilities can be prevented by using parameterized queries, or prepared statements, rather than string concatenation, which allows unrestrained user code to interact with the server database, in a potentially malicious way.

Some vulnerable applications, when exposed to a SQL injection, will return information confirming the existence of a vulnerability in its HTTP responses. However, many will not. If an attacker cannot see the results of an injected SQL query, it may be difficult to discern whether or not the injected code actually had any impact at all. If the SQL injection affected the application, but the attacker cannot see the results, this is known as a blind SQL injection vulnerability. There are multiple effective ways to confirm a blind SQL injection vulnerability, and in this article we will be exploring the technique of triggering time delays to confirm if such a vulnerability exists on an application.

To demonstrate this technique, I will be using the free community edition of Burp Suite to examine a vulnerable web application hosted by PortSwigger in their Web Security Academy. Other tools I will be using include the Firefox web browser, and FoxyProxy, which is an add-on for the Firefox browser. These tools can be downloaded for free at the following links:

Burp Suite: https://portswigger.net/burp/communitydownload
Firefox: https://www.mozilla.org/en-US/firefox/new/
FoxyProxy: https://addons.mozilla.org/en-US/firefox/addon/foxyproxy-standard/

First, we need to access the ‘Blind SQL Injection with time delays’ lab on Portswigger’s Web Security Academy. You can sign up for the academy here:

https://portswigger.net/web-security

We are presented with an online web shopping application. I have already opened Burp Suite and have it running, so I will open FoxyProxy to select Burp Suite. This passes all communications with the app through Burp Suite itself, allowing us to manipulate our requests.

Next, we need to change the scope and settings in Burp Suite to focus on this website only. We navigate to the target tab on Burp Suite, click on Scope, and then click Add. Here we will paste the URL of the target web application. Click ‘OK’ to save the target scope. Then, click ‘Yes’ to avoid accumulating project data for out of scope items.

Next, go to the Proxy tab on Burp Suite, and click on Options. Under ‘Intercept Client Requests’ check the box next to ‘And’. Under ‘Intercept Server Responses’, check the box next to ‘And’ as well. This will further narrow the scope of our operation.

Go to the Proxy tab, and select Intercept. Click the box so it says ‘Intercept is On’. Then, go to the target application in our browser, and click the refresh button. This will populate an HTTP request in Burp Suite. We have successfully intercepted the packet on its way to our target website. We can now manipulate it in any way we see fit. Particularly of use to us, in this case, is the ‘TrackingID’ value under the Cookie header. This site uses cookies to track its users, likely for analytics purposes, and each user is assigned a unique Cookie/‘TrackingID’. The application performs a SQL query containing the value of the submitted cookie/Tracking ID. This is the field we will manipulate to execute our SQL injection attack.

Click on ‘Forward’, and the packet will go through, without any manipulation on our part. The web app will load quickly in our browser. Take note of how long it takes for the application to respond to our request.

Next, we will use SQL injection to determine whether or not this website has a blind SQL injection vulnerability. Since the app uses a cookie to query a server-side SQL database, we can input our SQL code under the ‘Cookie’ header. We will replace our given ‘TrackingID’ value with the SQL injection code that will trigger a time delay. The code is below:

TrackingId=x’||pg_sleep(10) —

Next, hit ‘forward’ to send our manipulated packet. Take note of how long it takes the application to respond to our request.

If successful, the application will take ten seconds to respond to our request. This alerts us to the presence of a blind SQL injection vulnerability.

An important thing to note, is that different database platforms will use differing SQL language implementations. So, our attack syntax will vary, based on what back-end software the target application is using. A very helpful guide to determine the proper syntax for a SQL injection attack is linked to below:

https://portswigger.net/web-security/sql-injection/cheat-sheet

Once a blind SQL injection vulnerability has been confirmed, an attacker is in a powerful position to execute malicious actions against the application. It will be difficult, since the application will not show any of the desired information in its HTTP responses (hence the name — blind SQL injection vulnerability). However, an attacker can use out-of-band (OAST) techniques to retrieve desired information from the target. OAST attacks are effective and efficient, but can be prevented by practicing preventative security. Deny any attackers the opportunity for an SQL injection in the first place. Make sure that unsanitized user input is not allowed to interact with the application’s database. Parameterized queries are much more secure than string concatenation queries.