Can Blind SQL/Boolean Based SQL Injections not contain break characters or comparisons?

Question

I'm using a scanner which passes subtraction attack traffic such as (1-1), (3-2), (5-2), etc. There are no break or continuation characters such as semicolons or &&, nor is there a comparison using an equals sign or similar (and not function call). These are submitted using POST as part of a form. Is this possible?

Answer 1

It's important to remember that a scanner's job isn't to exploit a vulnerability - it is to find a potential vulnerability. Imagine code like:

sql_query("SELECT * FROM `table` WHERE id=" + request.get('id'));

This code is vulnerable to SQL injection. You could imagine doing your typical fancy SQLi payload which joins some tables from the information_schema database, tries to figure out column names and add them into the response, etc...

The problem with that course of action as a first step is that a complicated injection payload may get blocked by a WAF or similar technology. As a result, you may end up moving on without realizing that there is an actual vulnerability there. Also, getting reliable output back out can be quite tricky and application dependent, and often beyond the "smarts" of an automated scanner.

In contrast, (5-3) is a pretty simple payload comprised only of standard ASCII characters, has a high chance of bypassing a generic off-the-shelf WAF, and likely gives simple output that a scanner can easily understand. Consider the results of three requests:

1. https://example.com/widget?id=2 (200)
2. https://example.com/widget?id=34343 (404)
3. https://example.com/widget?id=(5-3) (200)

This is boolean based SQL injection. Which, to boil it down, means that the goal is to get a simple and easy-to-understand true/false out of the application. Especially since most systems will return a 404 for a non-existent page, it's quite easy for the scanner to try to detect the success condition. That last result becomes especially interesting when the scanner compares the full response body of #1 and #3, and discovers that they are identical. The scanner can now report with high confidence that there is an SQLi vulnerability on the id parameter of the widget endpoint.

In contrast, if there was not an SQLi vulnerability, then (5-3) would most likely be treated as a string, the underlying SQL query (id='(5-3)') won't match anything, and https://example.com/widget?id=(5-3) will return a 404.

Of course, this injection payload is very useless and won't help with an actual exploit, but as one of many possible tools to try to find vulnerabilities with a minimum of false negatives, it can be useful. The scanner might then follow up with more complicated payloads. If those get rejected then you can move on to the more fun task of trying to put together a WAF bypass.