How we look for Blind SQL
When testing a parameter for Blind SQL we send two types of requests, twelve of each. In simplified terms, one can be said to be a sleep command that, when successfully executed, makes the server wait a while before responding with the response. The other is the same, but with much lower delay.
After all 24 requests we measure the time difference between these two types of requests. If the timing difference between these two shows a clear pattern where the longer delay takes more time than the other, we believe the parameter to be vulnerable as the payload clearly got executed.
In the finding we present a graph where all requests and the time they took are visible.
Please observe this is a somewhat simplified explanation. We do some magic to minimise false positives, deal with caching etc. as well.
Why false positives occur
As we determine if a parameter is vulnerable or not by looking at a timing difference, some false positives will occur. Due to the amount of requests we do, randomness should not play a big role, but sometimes the right requests get delayed while the others do not, and we therefore think the parameter to be vulnerable.
When this happens, just report it as a false positive and it will automatically be marked as such in future reports so you will not be bothered by this if it would occur again. Most often these false positives only occur once though, as the circumstances causing the delays have changed before the next scan.
Read more
This method of testing is called Time-based Blind SQL injection, and you can find more information here if you are interested in reading more: http://www.sqlinjection.net/time-based/
If you have any further questions, feel free to drop us a line at support@detectify.com.