Using Burp to detect SQL Injection Vulnerabilities

I was working on a clients web-app the other day. I had to set off an automated scan using Burp across the site.  Burp is a great tool for providing coverage of web-apps and their vulnerabilities. It can be surprisingly good at detecting XSS and SQL Injection vulnerabilities.

For obvious reasons I can’t say which web app. But this particular one had JSON variables that were wrapped into a single “GET” parameter.  This something like this:

index.php?query={"name":"Felix","profession":"Geek"}

Burp had detected that it was getting some interesting output from one of the JSON variables when it inserted a single quote like this:

index.php?query={"name":"Felix","profession":"'"}

The output from the site was a fairly restrictive.

PHP error so didn’t immediately provide any particularly useful information. But was still reported in Burp as a potential SQL injection vulnerability.  Usually, if Burp picks up SQL injection, SQLMap sees it pretty much straight away.

So I fired it up and was hopeful… but nothing came up.

Having no result from SQLMap doesn’t mean there is nothing there.

So I decided to poke around manually to try and verify the findings. 

My aim was to reveal some useful information that I could relay back to the client to try so that I could positively confirm that there was SQL Injection.

When error messages produce no useful information you are at best looking at a Blind SQL Injection vulnerability.

Which means that it behaves correctly but doesn’t echo anything.  This makes data exfiltration very slow as essentially you have to play a “true” / “false” game with the SQL server. 

This particular error message was from a PHP function. It seemed to be complaining that it was receiving more data or at least data in a format other than that it was expecting.  What this means is that the error is only going to get produced when there is more data in the SQL return. Therefore the error message means my guess was “true”.  None of this is particularly relevant to my post though, just setting the scene.

I ran SQLMap again and this time I specified my Burp proxy server for it to use so that I could see the raw requests and responses.  Something like the following should do the trick:

--proxy http://127.0.0.1:8080

I could see in the Burp History tab that it wasn’t injecting in the right place, I had specified the right “GET” variable, but the reality was that it was only a small part of this variable that was vulnerable.  A little research later and I discovered that there was an option that would allow me to specify where I wanted SQLMap to play.  Along with your other options such as –level 3 etc. you need to do something like the following:

-u http://www.victim.com/index.php?query={"name":"Felix","profession":"*"}

Note the asterisk (*).  This goes where you want it to inject.  And voila!  This time it works.

Act before it is too late, contact us and learn how your organisation can prepare for cyber attacks