search

zaproxy / zaproxy

The ZAP core project
https://www.zaproxy.org
Apache License 2.0
12.5k stars 2.23k forks source link

SQLI false positives due to WAF #4536

Open AppSecBloke opened 6 years ago

AppSecBloke commented 6 years ago

ZAP sends a normal HTTP request to a web application and gauges the response time: 325ms

ZAP sends a modified HTTP request to the same web application and gets a different response time: 14ms (This is because ZAP hits a WAF)

ZAP reports a time base SQLi vulnerability, which is a false positive, because...

The normal HTTP request gets a proper (HTTP 200 response), i.e. a served page, whereas the modified request gets dealt with by the WAF, i.e. a quick go away (HTTP 418 response).

Time to load the 200: 325ms

Time to load the 418: 14ms

Ergo: Response time difference in ZAP terms = web application is susceptible to time based SQLi

ZAP displays similar results in other SQLi tests.

Also, configuring authenticated scans against Windows based applications that use NTLM is extremely difficult to get working and actually required cntlm and Fiddler acting in a 'double proxy' capacity to get working.

The native NTLM configuration in ZAP simply didn't work, no matter what configuration was applied.

psiinon commented 6 years ago

Please dont report multiple problems in one issue - it makes it really hard to track them and understand whats fixed and what isnt. I've updated this issue to just apply to the SQLi / WAF issue.

kingthorin commented 6 years ago

@AppSecBloke are you times backwards? (Or did you miss a digit or two?) If the modified request took less than the original then you should not have received an alert?

AppSecBloke commented 6 years ago

Hi kingthorin,

No, the point is that an unmodified request returned the page in full, hence taking longer to respond due to all content being served.

A modified request returned a practically empty response (a HTTP 418 error), which took considerably less time to serve. Hence it looking like a time based SQLi possibility.

Therefore ZAP appeared to see this as a vulnerability, when in fact it was hitting a WAF with its injection attempt.

:)