This post is the second in a series of noob-friendly posts that I am doing on SQL injection. Earlier I explained Second Order SQL Injections with Example. So in this post, I will be explaining the HTTP header Blind SQL injection, I prepared a Demo for the HTTP header Blind SQL injection For Example, HTTP has many reserved header fields the header I am choosing for the demonstration is the referrer header.
What is HTTP Referrer Header?
A referrer header is an HTTP header field, it’s simple job is to identify where the request originated from, for example, if you search for something on google and click on search results, your referrer header value will be something like https://google.com. If you click on facebook.com right now, your referrer header will contain the value https://haiderm.com/http-header-blind-sql-injection-example because this URL leads you to facebook.com.
What is Blind SQL injection?
Blind SQL injection is a type of SQL injection attack that asks the database true or false questions and determines the answer based on the application’s response. In Error-based SQL injection, retrieved data is visible on the page, but in Blind SQL injection, data is not shown on the page (hence the name BLIND) though attacker can still retrieve/guess data by asking series of questions True or False questions from the database. For example:-
' AND 1=1# //Asking if 1=1 , which is true and page loads normally
Now if the response from the server is different, which can be determined using Burp Suite Comparer it compares response of two pages and let you know the difference in terms of text, response time, response codes etc, then it means its vulnerable to Blind SQL injection, if the response is the same, then its not vulnerable.
HTTP header Blind SQL injection Example
It simply means, Blind SQL injection Vulnerability in HTTP header fields, for demonstration we are taking an example of referrer HTTP header. For demo purposes I created an application, which will check for referrer field value, if it matches with the value in application, it will redirect to another page “purchase.php”. So firstly it has the following login page:-
After login, if our referrer field value matches with the referrer field value set in application, it will redirect to another page “purchase.php”.
My Referrer header value is:-
Referrer Header Value set in Application is:-
I login, and it redirects to “purchase.php” page, because values are matched:-
You might be thinking, well obviously after login our referrer value will always match with the referrer value set in the application. A part of it is true, although consider the scenario where an attacker sets a link in his malicious page to “purchase.php” with parameters such as buying something, and you click on it, the attacker will be able to execute actions on your behalf, resulting in impersonation of your role on the application. This is exactly the CSRF behaviour. If the referrer check is in place, attacker won’t trick you jumping “purchase.php” directly.
Attacker’s Point of view
Now consider this from attacker’s point of view, you are pentesting an application, you got into the admin panel via authentication bypass, or even in some cases, or you already have the credentials if you are doing whitehat penetration testing and you want to investigate it from admin’s role (Btw don’t get confused by login requirement, the vulnerability doesn’t require you to be logged in). So you are in admin panel and you start playing around. Its easy to find that you can’t directly access “purchase.php”, but why is that, when you login, it redirects to purchase.php , but if you copy purchase.php’s link and paste it in browser, it won’t let you get to it. The answer is simple, referrer header (its a bad bad idea to have referrer header as an authorization control). So lets play around with referrer header.
So When I change referrer to http://google.com, it rejects my request which indicates following useful things:-
- There is a legit referrer header.
- referrer header is stored and being used again to check either user referrer is same as stored in DB.
This gives a clue that database is involved in it, as referrer header is stored and checked again, which leads to playing around with referrer header for SQL injection Vulnerabilities.
Here is the payload I used for testing Blind SQL injection:-
'OR(select 'abcD' from DUAL where 1=1 and SLEEP(5))OR'
For my query to wait 5 seconds, the page responded after 5 seconds. Checkout bottom right mills in the above screenshot. Which means that yes, its vulnerable to Referrer based Blind SQL injection. allow me to explain the query:-
I want the database to wait for 5 seconds before responding, DUAL is a dummy table in MYSQL, its used when data is not used from tables, which makes it a perfect candidate for executing our queries in Blind SQL injections because we don’t know any of the table names of victim’s database.
Let the magic of SQLmap Flows
Well, we have found a Blind SQL injection vulnerability in referrer header, contrary to error based SQL injection, blind SQL injection cannot be performed manually (unless you have a week of free time and a lot of patience). Some tool or script is required to retrieve data using automation. For this task lets fire up SQLmap and let it do the rest.
Python sqlmap.py -u localhost:8085/pentest/referrerHeaderSQLinjection/ --data=uname=admin&passwd=admin&submit=Submit -b -p referrer -dbms=MYSQL --level=5 --risk=3 --threads=10 --banner
Payload usage and its description below:-
Specifies the Test URL.
The POST request body values.
Testing for Blind SQLI.
Specifies test parameter, which is referer in this case.
Specifies the test database, no need to flood requests specific for other DB's.
Level specifies the depth of testing, for HTTP header SQLi testing Level 5 required.
Kind of same function as –level. It also describe the noise of requests max value is 3.
Show the target's database banner.
Number of concurrent threads, more threads more speed, maximum value is 10.
It exploits the vulnerability and shows the banner that we asked in our payload, we could do further exploitation by dumping information, but this is enough for the demo purposes. When doing penetration testing and bug bounties you must look for header based SQL injections, these are not very common but not usually tested as well which makes them a good target. Below are few of the real world bug bounty examples:-