Learning Web-Sec - Day 4 - PortSwigger SQL Injection Labs

Blind SQL Injection.

Published in

System Weakness

7 min readDec 30, 2022

Follow me for more such content as it helps me stay motivated for writing such detailed walk-through.

Wait, before moving on to the blog, can you give me a follow? It really helps me stay motivated to keep writing such detailed blogs. We’ll have today as our off day due to not being well. Wait, It’s not fully off, but just a single lab on blind SQL injection to give you an overview.

Why do we need to worry about these?

See, All the injection attacks we went through in the previous labs had something common that’s different from the blind SQL injection attacks. And you can guess that from the word BLIND.

You maybe on the right side of thinking what blind SQL injection attacks are. Lets find out.

So, What are blind SQL injection attacks?

Consider a scenario where there’s data being transferred to the server from the web requests but the HTTP response doesn’t contain the result of the SQL query or there isn’t a visible “Internal Server Error” message because the webpage was designed not to do so.

But this doesn’t mean that SQL queries are not running anywhere. I mean, think of big websites where you think a database is not required. Can’t think of one, right? Me Too.

This might be a case of blind SQL injection. So, Now that you know why Blind SQL Injections are important, Let get started exploiting them.

For this lab, we will need a proxy(Burp or ZAP) to intercept and repeat requests.

Lab 11 — Blind SQL injection with conditional responses(Link)

Level : Apprentice

Description Of Lab :

This lab contains a blind SQL injection vulnerability. The application uses a tracking cookie for analytics, and performs an SQL query containing the value of the submitted cookie.
The results of the SQL query are not returned, and no error messages are displayed. But the application includes a “Welcome back” message in the page if the query returns any rows.
The database contains a different table called users, with columns called username and password. You need to exploit the blind SQL injection vulnerability to find out the password of the administrator user.
To solve the lab, log in as the administrator user.

So, Get your favorite proxy tool and let’s start intercepting some traffic. My personal fav. is OWASP’s Zed Attack Proxy but you can use Burp Suite, That’s a pretty good tool too. And I usually like to use the inbuilt browsers from ZAP or Burp. Saves time and also you don’t get tonnes of unnecessary requests in the history of your proxy.

I’ll just launch Firefox from here and as soon as I start surfing the lab’s webpage, We’ll start seeing the requests in the history tab.

Now select the web request which has a form in it. Which is the login page. And we’ll now look at the HTTP request made.

Here we see a tracking ID. Now let’s try modifying the tracking ID and see if we see any difference in the web page. For that right click anywhere on the request box and select the “Open/Resend with Request Editor” Option.

Here I’ve edited the TrackingId and appended the string “hehe” to it.

We can see the difference in the size of response of original and edited requests which is a difference of 41 bytes.

Further investigating, we find that if the TrackingId has the right value, we see a “Welcome back!” string.

And if the request has a bad value for TrackingId, the “Welcome back!” string vanishes. Like here below.

We will now try exploiting this parameter for possible SQL injection vulnerability.

And let’s try to think about what SQL query might be going on inside the backend of the application. It’s possible that it might look something like this :

FROM tracking SELECT * WHERE TrackingId='W0eYyaVPHM3ny8gw'

Now if this query returns a value(row/record), this would indicate the value True in boolean and if it returns an empty set, this would indicate False. If the application gets a True value, it prints “Welcome Back!” alongside Home and My Account. So, we can try making the value true for checking if blind SQL injection vulnerability exists.

So, Here’s our request editor and were ready to inject SQL.

Request 1 :

Response 1:

Wait, i know you’re excited seeing this. We’re Welcomed By The Application, But this doesn’t make sure that it’s because of the SQL we injected. I’ll tell you why in a bit.

Request 2:

Response 2:

Now It’s the time to celebrate. We’re now sure of the app being vulnerable to SQL injection.

If you’re guessing why now? That’s a great question. And To Be Honest I’m not an expert about the why but, Do you think that computers are highly programmable? Of course they are, and you’re right. So what if the app was programmed to take only the value of TrackingId as long as they’re from the set [a-z][0–9] and as soon it get’s a special character, it’ll terminate the value of TrackingId. If that would’ve been the case, We would’ve gotten the same response in both the cases as we’ve used a the ‘ character.

We clear now? Great, Let’s move on now.

And, let’s try some more injections(I Used to be scared of them as a kid, But these are interesting.)

Response 3:

Another Response where we succeeded getting “Welcome back!” in the response. And using this, we’ll be able to extract the password of the administrator. Let’s see how.

Not Lucky Enough. Let’s try other possible combinations of characters.

Now that we have our fuzzer opened. Let’s feed it payloads(the thing’s we wanna try, i.e. all the lowercase characters and numbers). Select Payloads Option.

Add the characters and start the fuzzer.

In our responses of fuzzer, we have a request that stands out. The one with a Response size of 2963 bytes. Got it? Extra size for the “Welcome back!” message.

So, now we know that the first character of password is h. Let’s find the others using the same method. By fuzzing with possible characters for all locations.

Starting the fuzzer for possible characters at possible positions, We already started getting the password, one character at a time. And I’ve sorted the requests by the size of their responses, this way it’s easy to find the responses which have the “Welcome back!” string.