Interpreting ZAP Results

[AGD]

Hi, all, brand new to this group.  I'm trying to work through a ZAP report of potential vulnerabilities for a site that has been hacked (I haven't run the tool, just been handed the colour-coded report).  I've gone through the critical items, and looked at the underlying code--fixed a couple of things, determined that some other things were false positives.  My IT contact I think expects to be able to run a scan at some point and have 0 issues; is this realistic?  I'm working on the assumption that a human needs to critically evaluate each of the potential vulnerabilities, but since this is just an algorithm, there will necessarily be false positives.  If I am correct, is there some manual page about what to do with the results--I couldn't find one going through the wiki.  Individual results in the report say "SQL Injection may be possible," but my contact reads this as "SQL Injection IS possible." Two very different things.  Obviously, I want to be safe, but I need to get my server back on line, and there are some false positives (links on my pages to sites that themselves have potentially fiddle-able parameters) that I just can't fix.

Thanks so much for any thoughts,

Andrew

[kingthorin+owaspzap]

Unfortunately false positives are a fact of life in any kind of automated assessment.

There are a few things you should consider here:
1) An assessment based on the results of a single tool is somewhat limited. If you are confident (and can provide technical details to back yourself up) that some of the results are false positives then you should report them as such and it should be up to whoever produced the assessment report to prove that you've overlooked something and the app is in-fact vulnerable to SQLi, etc.
2) It isn't entirely unrealistic to expect a clean report at some point. But that needs to be based on the understanding that false positives do happen (again you'll have to backup your position on those).

I'm working on the assumption that a human needs to critically evaluate each of the potential vulnerabilities

Absolutely. Further a human should also be critically evaluating the target, while automated scanners are great there are things they simply can not do.

but since this is just an algorithm, there will necessarily be false positives

Again, this is true of any automated tool.
The dev team does it's best to eliminate conditions that might result in false positives (to that end, any specific examples you can provide are greatly appreciated). However, in order to ensure we are not allowing false negatives things need to strike a balance in interpretation of results and tests performed.
Further ZAP does allow a critical human ;) to set the "Confidence" of results including setting them as "False Positive".

and there are some false positives (links on my pages to sites that themselves have potentially fiddle-able parameters) that I just can't fix

That doesn't make the result a false positive, that just makes it outside your scope. Perhaps your client should be leaning on their other service providers as well. (Unless you "own" the relationship with those 3rd parties.)

What you're seeing might be something like:
https://github.com/NESCent/FossilCalibrations/issues/33
<shrug>

Without further specific details it's hard for us to interpret further.

[Andrew Darby]

Thanks so much for your thoughtful response.  Unfortunately, I didn't set up the parameters for this scan, just received a .html results page.  An example (where I've tweaked the parent URL) is:

http://someplace.com/employment/%5C%22http:%5C/%5C/someplace.hodesiq.com%5C/job_detail.asp?ViewAll=%5C%22&JobID=4798841%22+AND+%221%22%3D%221%22+--+&user_id=

In this case, it has taken a link from the /employment/ page and tacked it on to the end of the WordPress URL.  This triggered a Red/High (medium) vulnerability--I'm not 100% sure why it was flagged this way, if it was because WordPress (the site software) redirected this no good URL to a 404 page, when something without WP's complicated rewrite rules would have behaved differently; or something else was iffy about the response.

Let me also say I'm not trying to criticise this tool; I understand completely why false positives are going to crop up, I'm just not sure my IT contact does :)

Thanks!

Andrew

--
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/bCr4V-Hns6A/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.

[kingthorin+owaspzap]

In that case I'd guess that the report output is somehow mangled, I can't say where or how for sure. The item you should be concerned with is whether or not job_detail.asp is subject to SQLi (in the example below, specifically the JobID parameter).

I'm guessing that ZAP interpreted the base response (from a request without any SQLi) to be the same (or significantly similar) to a request there JobID was SQLi'd to produce the same result set.
i.e.: JobID = 4798841
is logically equivalent to
JobID = 4798841 and 1=1

This could be a false positive if JobID 4798841 has expired and always returns a basically NULL result (or 'please search again' type result).

To validate (with appropriate permission of course, esp if this is a third party), you could try with "and 1=2" which of course shouldn't be logically equivalent and generate a completely different result (perhaps even an error, in which case if it's a SQL error you may still have an issue)....hopefully you get the idea.