Sql injection false positive

[Merok]

Hello,

when scanning WackoPicko the scanner reports some very strange false positives: 

We can observe on the Request:

POST http://x.x.x.x/WackoPicko/cart/action.php?action=addcoupon HTTP/1.1

Host: x.x.x.x

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;) AND 1=1 --

Pragma: no-cache

Cache-control: no-cache

Content-Type: application/x-www-form-urlencoded

Content-length: 14

Cookie: PHPSESSID=vl8carc7leggb6emute5kmdtl7

And if we read the Other info:

The page results were successfully manipulated using the boolean conditions [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;) AND 1=1 -- ] and [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;) AND 1=2 -- ]

The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison

Data was returned for the original parameter.

The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter

Do you have any idea why Zap reports this as sql injection ?

(I'm using the 2.2.2 version)

Thank you for you help !

Merok

[Colm O'Flaherty]

Hi Merok,

It looks like the web app does something with the user agent value, because the scanner thinks it managed to restrict the results by changing the condition to an "always false" condition (which in *most* cases reduces the results returned by the SQL query).  It also checked (by appending an "always true" condition) that it could re-generate the original result, using SQL injection.

This logic is generally fairly sound, but the red flag here for me is the that that the 2 expressions given would not be syntactically valid SQL.

You could always turn off the scanning of headers in the Active Scan Options to reduce false positives in this case.

Is there more info to be had on the requests and responses in question?  Without that, it's hard to be more specific.

Colm

[Merok]

Hi Colm,

thank you for your answer. I would prefer not to disable the headers vector because I don't want to reduce the scope of the analyze.

"Is there more info to be had on the requests and responses in question?  Without that, it's hard to be more specific."

=> what kind of info are you think at ? I don't really know what info to give you. This sqli false positive has been triggered while scanning WackoPicko.

This seems to be a bug in the software because it does not appears every time and the same false positive has been triggered by the scanner on other website.

Do you have any idea why the scanner would considerate a vulnerability with such input ?

Thank you in advance!

[Colm O'Flaherty]

Hi Merok,

That's fair enough.  I can understand why you don't want to disable headers.

I'll download WackoPicko and try it out.. in the meantime, can you give me some details on the following:

- which precise Zap version

- which OS

- which specific plugins you have enabled in the scan policy

- what attack strength and thresholds value you're using in the scan

- which specific plugin is raising the alert (or the title of the alert, if you're not sure)

- what mechanism you're using to scan the URL (as part of a context, or as a single url, for instance)

- how many scanning threads are enabled in the options

I might have other questions.. I'll see how I get on with WackoPicko.

Thanks,

Colm

--
You received this message because you are subscribed to a topic in the Google Groups "OWASP ZAP User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zaproxy-users/Gg5I9MSLnJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zaproxy-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Merok]

Hi Colm,

thanks for your answer. I've redone tests on wackoPicko and I don't get this results anymore... However when I scan my private website I always get up to 10 sql injection false positive of this type.

Here are my configuration:

- which precise Zap version => 2.2.2

-Owasp BWA version => 1.1.1

- which OS => Kali Linux 3.12

- which specific plugins you have enabled in the scan policy => Path traversal, remote file inclusion, Url redir. abuse, server side abuse, server side include, Sql injection, directory browsing, secure page browser cache, external redirect, parameter tampering. (for passive : Cookie no http-only flag, cookie without secure flag, session ID in URL rewrite)

- what attack strength and thresholds value you're using in the scan => Medium/Medium

- which specific plugin is raising the alert (or the title of the alert, if you're not sure) => the name of the alert is "Sql injection)

- what mechanism you're using to scan the URL (as part of a context, or as a single url, for instance) => I crawl manually the root address manually with the proxy. Then I use spider-subtree (on the root adress in History). Finally I click on the same link on History on attack-active scan subtree.

- how many scanning threads are enabled in the options => 10 threads for attack.

Here are two more examples of sql injection Zap alerts when I scan my personal website:

POST http://www.example.org/report HTTP/1.1

Host: www.example.org

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;) AND 1=1 --

Pragma: no-cache

Cache-control: no-cache

Content-Type: application/x-www-form-urlencoded

Content-length: 302

SQL injection may be possible

The page results were successfully manipulated using the boolean conditions [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;) AND 1=1 -- ] and [Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;) AND 1=2 -- ]

The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison

Data was returned for the original parameter.

The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter

----------------------------------------------------------------------

POST http://www.example.org/report HTTP/1.1

Host: www.example.org AND 1=1 --

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;)

Pragma: no-cache

Cache-control: no-cache

Content-Type: application/x-www-form-urlencoded

Content-length: 302

SQL injection may be possible

The page results were successfully manipulated using the boolean conditions [www.example.org AND 1=1 -- ] and [www.example.org AND 1=2 -- ]

The parameter value being modified was NOT stripped from the HTML output for the purposes of the comparison

Data was returned for the original parameter.

The vulnerability was detected by successfully restricting the data originally returned, by manipulating the parameter

Thank you very much for your help!

Merok

[Colm O'Flaherty]

Much appreciated for the extra info.

Does your logic do anything dependent on the User-Agent header value, by any chance?  Does the app serve different content depending on the browser, for instance?

Can you give me a specific URL in an app that I can deploy and test on my own machine?  I run the same version of Kali as you, so this should be fairly meaningful comparison.

Thanks,

Colm