Requests for ZAP API and Active Scans

[Sherif Mansour]

As a security engineer I want to use ZAP for security tests which are:

• Automated: The ability run repeatable security tests as part of the build pipeline.
• Useful: Improves the security and code quality of web applications.
• Actionable: The information provided is enough got developers to replicate and resolve the security issues   

In order to meet these requirements I need more flexibility in ZAP and more accurate Active/Passive Scans.

Automated test use case:

• Zap initialized to run Live active-mode/passive scanning on a specific scope
  
• Turn on zap in headless mode
  
• Add host into scope via zap API
  
• Run traffic through zap proxy
  
• Zap performs live active and passive scanning on said requests
  
• Zap notifies that the test is complete via zap API or other
  
• Pull results and zap state as artifacts via zap API
  
• Delete host from scope via Zap API
  
• Close Zap

Active Scans:

Leverage exploit knowledge databases such as http://www.exploit-db.com/webapps/  in order to:

• Check if ZAP currently would pick up real world web app vulnerabilities
• And if not, improve the ZAP scans to pickup the ones that it didn't
• Such As:
• CVE-2014-3704 Drupal core - SQL injection http://www.exploit-db.com/exploits/34992/
• Wordpress Lazy SEO plugin 1.1.9 - Shell Upload Vulnerability http://www.exploit-db.com/exploits/28452/
• Blind SQLI scan pet peeve
• Sometimes there are pages that will return a different response for the same request each time.
• Example: when a page responds with a unique timestamp or random nonce
• If an SQLI test does not take that into account, they will assume since the true/false requests are different therefore something is wrong.
• Recommendation:
• Run the true request several times to detect differences in the responses
• Run the false requests several times to detect the differences in responses 
• If there are still more difference between the true and false responses, then you have a higher degree of confidence that of a potential SQLi

[kingthorin+owaspzap]

Great feedback.

One of the most wonderful things is that ZAP is an open project and you're more than welcome to contribute.

That being said I'll see if I can address some of that:
1) In your use case, is there some reason to remove the host from scope before closing ZAP? There are lots of threads in this group[1] about using ZAP's API[4] and CLI options, as well as some youtube videos on ZAP in CI streams etc [2].[3][5][6]
2) Though we'd be glad to have people develop scanners for every known or publicly available vulnerability/exploit I don't believe that's the niche we're trying to hit. I feel that ZAP is aiming at identification of zero day issues. So while we might not find CVE-2014-3704 and list it as that specific CVE, we should find it as a SQLi if you're running an affected version of the product in question.
3) Understood and agreed, lots of Blind SLQi scanners are subject to this issue. I've hit this with Burp, IBM AppScan, etc web application behavior is hard to account for. I've seen bSQLi false positives caused under lots of conditions as you've described. The question is how to define "several" for one app 3 might be enough to differentiate or increase confidence while for another 5 or 10 might be the mark.....

[1] https://groups.google.com/forum/#!forum/zaproxy-users
[2] https://code.google.com/p/zaproxy/wiki/SecRegTests
[3] https://groups.google.com/forum/#!topic/zaproxy-develop/KPeQK3Iwhmw
[4] https://code.google.com/p/zaproxy/wiki/FAQhowtousezapapi
[5] https://www.youtube.com/watch?v=aVFZFi_6B9g
[6] http://duncan.mac-vicar.com/2014/07/21/security-vulnerability-regressions-and-continuous-integration/
I'm sure there is plenty more out there.

[Sherif Mansour]

1) Having spoken to Simon Bennetts, it looks like the API will not alow the polling of the state of active scans during attack mode (the one similar to burps live active scans) the reason to remove the scope at the end is to return zap to its initial state for the next test to come along.

2) Thats not exactly what I meant, the intention is to check if the scanner would pick up known real world examples of web app security bugs, learn from them and tune the scanner in order to be able to do so. I did mean to have a scan rule for every CVE, but to ensure that the scan rules are sharp enough and to check that they would have retrospectively picked up these issues. IF not then why and learn from them to improve the scan rules.

3) I don't think the number is as important as picking up the parameters that change. So for a given page, once they are identified you can stop making the same requests. As you have said some might take 3, others 10, but we would be in a much better place than where we are now.

[kingthorin+owaspzap]

Hey Sherif,

1) Got you, makes sense. When I saw your original set that had remove then close, the remove step seemed redundant. If there are some repetitive steps in the middle then it makes more sense.
2) It should pick up all standard types or classes of vulnerability. Obviously despite attempts no tool is ever 100% accurate. I like the idea of some sort of "learning" and "tuning" going into the process but I think we'd need that handled via GSoC or something like that....someone that needs a task for their masters or doctoral thesis :)
3) I think at least some of the existing SQLi scanners try to do this by looking at largest common sub-strings within the test responses. Thus discounting minor changes via nonce or cookies, etc There might be options for improvement. There's still a lot of design that needs to be done here, in theory you could end up with endless requests that produce variation in response so getting the logic just right is non-trivial. Such logic would also need to consider that /getProduct?prodId=1 and /getProduct?prodId=100 (both valid) may produce vastly different responses to start with (not even considering the results of an injection attempt [which could result smaller, larger, within range, or completely different [esp with blind injections]).

[Sherif Mansour]

Cool,

2) I feel this is challenging enough that it can't be just for an Msc, but the wider OWASP community because it would require people with different skills collaborating. Think about Reflected File Downloads or External Entity Injections

• The security research who discovered such issues might not be a knowledgeable enough of ZAP or other tools to write a scan test for them.
• Additionally a ZAP developer might not understand the attack well enough to pick up the different permutations of the attack assuming the researcher did a thorough enough job in the first place!
• Third of all you need to convince both parties that the vulnerability is worth writing a security test for and ZAP is the tool for the job.

I guess I feel there should be a process where the community says "Hey, there is an 0-day exploit on this open source project. Lets check if ZAP would have picked it up. No? well lets see how we can improve the scanner to pick up such issues in the future".

3) Not to mention there is the timing/latency angle as well..i.e. can you make the DB pause for a few seconds, thus if the responses are delayed you know that there is a likelihood of success. 

Let me know if you are interested in investigating a process to identify room for improvement in ZAP scanning capabilities, so then bug tickets can be raised and prioritized to improve its quality.

[kingthorin+owaspzap]

I think all of the devs would definitely be interested in any and all suggestions you or the community have, none of my answers were meant to discourage you at all. I was just trying to provide context and thoughts on the matter. I can't speak for others but I don't currently have time to look into any of this, but others may and even if it doesn't come for 6mo, 1yr, etc having more idea or more info is never a bad thing (IMHO).

[Sherif Mansour]

Thanks I'll be in touch next week

[Sherif Mansour]

Oh! speaking of Reflected File Download Vulnerabilities: http://attack-secure.com/reflected-file-download-vulnerability-facebook-com-0day/#sthash.A53eYCtW.dpufhttp://attack-secure.com/reflected-file-download-vulnerability-facebook-com-0day/ 

On Friday, 20 February 2015 19:56:38 UTC, kingthorin+owaspzap wrote:

[Simon Bennetts]

I've just updated the API to allow the attack mode queue size to be read, so you can tell when its finished with its current set of scans :)

[Sherif Mansour]

Awesome! thanks Simon