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?

  • You mentioned blind SQL in your title, but it's not quite clear how Blind SQL factors into the equation. Presumably your scanner doesn't have any idea of whether or not blind SQL is required, and is just trying its usual strategies. Is this a page where you don't get any feedback from the injection attempts? Sep 11, 2019 at 19:12
  • The scanner reports back additional error text in the html (supposedly). I have not been able to reproduce. Sep 11, 2019 at 19:42
  • That's not unusual. Scanners like this are prone to false positives. Trying to automatically decide if a vulnerability has been found is actually quite tricky. Followup is always necessary, and you've got decent odds of not actually finding a problem. Sep 11, 2019 at 19:50

1 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.

  • You're saying with no inection vulnerability, then 5-2 will be a string id "5-2", but with a vulnerability it will be evaluated? Sep 11, 2019 at 19:45
  • @user8897013 correct. Presumably, "5-3" will not match anything (or at least won't match the record with an id of 2). I'll update my answer. Sep 11, 2019 at 19:47
  • As stated in my comment above, the scanner did report back additional error text in the html. Not sure why else they would call this a boolean based vulnerability if there's no boolean evaluation... I'm sure there are numerous variations on blind sql if there is any difference. I was originally suspect of this vulnerability because our framework is highly resistant to sql injection, but this obviously doesn't mean we are impervious. Sep 11, 2019 at 19:49
  • @user8897013 per my comment above, you can't believe everything a scanner tells you. Don't assume that there is a vulnerability just because the scanner says there is. You should be able to verify it yourself fairly easily though if this is your own framework you're scanning. Sep 11, 2019 at 19:53
  • Thanks for your input @conor... I needed some time to think about this. The example you gave reminds me more of straight sql injection where the value is actually evaluated, since in the case of boolean/blind based injection we are looking for errors/differences in the response as a result of the injection. Here is where I get confused with Blind/Boolean Inection: for most normal apps, I would expect that entering (1-1) for a post array value would return an error anyways given that it can't be evaluated if it's not converted to an integer (for an array index for example). Sep 20, 2019 at 20:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .