Burp suite: How to use burp to look for SQLi

Introduction

Testing for SQLi using burp suite is not something that's easy but burp suite does allow us several options to make it easier. The biggest problem with searching for SQLi is testing header values we can't normally manipulate without burp suite for example.

Testing blind SQLi in burp suite

Testing for SQLi might not always be very simple at all. Sometimes it can be as simple as inserting a single quote into every field you see that you suspect interacts with the database. Other times we will not get any feedback if a SQL error occurs so it might seem like the website is not vulnerable to SQLi while in actually it might still be.

In this example we are going to look at how to solve this lab first and then how we could expand on it.

Setting the scope

Link will be in the downloadeable resource.

To solve this lab we first have to set our scope correct ofcourse. When starting up the lab, we are given a URL. We can choose to only include this URL in scope or the domain name depending on what we want to do.

If we want to test for just this one lab we can keep the complete URL in scope.

Or we can select just the domain if we want to test more labs.

In reality it will heavily depend on the scope of your target what you set here but i will always use the advanced scope control giving me regex capabilities for if need be.

Make sure you also set the out of scope section propperly if need be.

Solving the lab

To solve this lab we need to visit the homepage and intercept the request. We then need to replace the tracking cookie with the following value:

TrackingId=x'||pg_sleep(10)--

How to test for this

Since we are talking about blind SQLi we will not be receiving information from the server to even confirm wheter or not we have a SQLi on our hands. In these cases we have several options that allow us to create a noticeable delay (for example a sleep of 10 seconds), however this sleep command will differ from database system to database system.

Oracledbms_pipe.receive_message(('a'),10)

MicrosoftWAITFOR DELAY '0:0:10'

PostgreSQLSELECT pg_sleep(10)

MySQLSELECT sleep(10)

We can easily manually test for all of these values

TrackingId=x'||dbms_pipe.receive_message(('a'),10)

TrackingId=x'||WAITFOR DELAY '0:0:10'

TrackingId=x'||pg_sleep(10)

TrackingId=x'||sleep(10)

What is happening here is that the server is executing a query in the background. By entering the single quote, we are closing that query, we can then add an OR statement (||). The last step would be to execute our command (see list above).

When the page loads for much longer than the other requests, we know we might have a blind SQLi.

Other options

We might want to try our SQLi with several other options besides our sleep command and maybe with a combination of single and double quote items. I think you can imagine how this can get confusing fast?

To not have to do this manually for every single request, we can send that request to the intruder.

Right click on the request and click "Send to Intruder". Ones in the intruder select the payload location that you want to test for. In our case we left the x'|| since it will be the same for all requests that we send:

We can then fill our payload options with whatever attack vector we wish.

We will then have to study every request to see if we can find requests that are different from the rest in any way.