Open AppSecBloke opened 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.
@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?
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.
:)
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.