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 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.
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.
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)--
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.