BToD Comparer tool & Basic Detection of BSQLi

This morning's Burp Suite Tip of the Day (BToD) will be about the use of the tool 'Comparer'. In this instance we are analyzing responses to our SQL Syntax (via SQLi). We are detecting SQL Injection but this technique can be used to modify your SQL Syntax to perform the attack correctly as well.

Today's tip is not completely about Comparer since we are also utilizing repeater as well which I've covered in the post Using Repeater.

So I've found my targets administrative login page. Maybe I've used "google" via "site:example.com filetype:asp inurl:/admin" search or simply had the directory listing up front. Either way, we have a target.

Overview:
We've sent the Login submission page to the 'Repeater' tool already and are going to begin testing the individual parameters for SQLi. The most basic test we are going to run is one tick/two tick i.e. Login_username=' and Login_username=''. We are interested in variances in the response based on this input. As a baseline, we've entered known incorrect credentials to the application (Login_username=Bugs+Bunny)and reviewed the response. This application uses the HTTP '302' Method (redirection) to throw users back to the main page in the case of invalid credentials.

This is important because if we were detecting Blind SQLi (which is what folks usually use the One tick/Two tick method for) we'd most likely be submitting the value 'null' when submitting Login_username=''. If SQLi is present, the null input should throw us back to the main page based on what we know of the application's behavior regarding invalid credentials.

To summarize, what I am showing you is not in any way shape or form a subtle difference in the application's response based on SQL Syntax. This is obviously not Blind SQLi. However, using 'Comparer' you most certainly would be able detect ANY difference(s) in the application's response.

Lets demonstrate this whole process and get familiar with the 'Comparer' tool.

We send the request to the application and await the response. This shows the single tick mark request/response.

Next we take the response to this request and send to comparer by 'right-clicking' on the response and choosing 'send to comparer' like so:

Repeat this previous steps only this time submitting the two "tick" marks.

(Sending to the 'Comparer' tool)

Navigate to Burp > Comparer. Screen would look like this:

Above you will notice I've highlighted #5 and #6. These are the numbers assigned to each piece of data you've sent to 'Comparer'. This is simply a nice feature for keeping track.

Okay, so now we want to analyze the differences in these responses. Now, obviously, we can see that a huge difference between these responses exist. One response is 514 bytes and  the other 16607. However, IF this was the case of an error handling page that was different from the normal response but only very slightly (Blind SQLi) we'd be in luck.

Anyway, for sake of providing an example, you'd click on 'compare.....' (bottom right) > words/bytes and the "word compare" screen will pop-up:

Three areas have been highlighted (well by me anyways). You can analyze words or hex so those options exist individually on either side. However, when both responses require scrolling and you'd like to compare side-by-side.........check the 'sync views' box. This is of great help. Also, when this box is checked you will notice that you only have to click text/hex on one side of the word compare tool and the other side will match up automatically. Also a great feature.

Happy Hacking!