Detecting SQL injections using a manual request is also an option. I recommend that you perform it when you are reviewing an application without a successful vulnerability detection.
First, we detect the entry points, as we reviewed in the previous section. To detect vulnerable points related to Blind SQL injection, you can use the following testing string:
' waitfor delay '0:0:30'—
We can also use its counterpart in the DBMS. But why should we do that? Well, as you may remember, the most important characteristic in Blind SQL injections is that they do not return errors or outputs directly to the user. So, by using this string, we are waiting to see the delay in the response:
- To cover more parameters, we need the Intruder tool. Do the same analysis about the parameters behavior to determine which request could be susceptible to being vulnerable and, using the secondary button of the mouse, click on Send to Intruder as follows:
- In Intruder, for a fast testing, add the delay query as the only one payload and launch it to all the parameters, as follows:
- Back in the Positions tab, click on Start attack. If you think you have detected a possible vulnerability, right-click on the request and select Send to repeater. Once you are in the repeater, modify the testing string to add more delay time, as follows:
' waitfor delay '0:0:10'—
' waitfor delay '0:0:20'—
' waitfor delay '0:0:30'—
' waitfor delay '0:0:40'—
' waitfor delay '0:0:50'—
' waitfor delay '0:0:59'—
The idea is to determine when to use the time to receive the response, if the vulnerability actually exists.
It is possible to use the Burp Suite Collaborator. It is a good trick to use it in these cases, as the Collaborator is an external entity that interacts as receptor to send the database's output, as shown in the following screenshot:
