ZAP: The UI and client API

[JCD]

Let me start with a little context. I am a QA engineer who specializes in automation and from a skill set has the ability to do development work. We have several hundred Selenium tests, but the majority of our testing is around the our APIs. We have mod-security which blocks most attacks before they can even begin. Our application also locks out attacks around bad credentials and uses anti-CSRF measures. Currently we have mod security disabled in the QA environment while I play with ZAP. Ultimately what I think we would like to do is have some sort of nightly automated security testing occur around the web application and possibly around the APIs.

While using ZAP I have found a large set of options and lots of hard to understand data. For instance, the Active Scan tab shows all the various URLs hit but doesn’t show WHAT the tool was trying to test. SQL Injection? XXS? I can’t tell. I try right clicking the grid, but no options seem useful. After several days of working through ZAP and watching youtube videos (thanks Simon Bennetts and others…) I have gotten a scan which scan our entire site, but now if I right click on my login page and choose ‘flag as context’->1 it no longer shows a list of contexts. Awesome.  Maybe it is because I set my entire site to the context, but how do I get back to the context UI now?

Really what I want is to not have the UI at all. Ultimately I want a nightly run with no human involved outside of review the results if they change. So I go looking for the Java version of the client software. Hrmm… No up to date maven repo. I guess I can put it in our local repo, but updates won’t get pushed to us nor can I automatically download the source code and documentation. Now that I have it in my repo, it seems to ultimately want to go talking back to the UI. This isn’t terrible, but why can’t I configure ZAP via an API and just run it by an API. Why do I need a ZAP UI application running somewhere in our VM farm playing proxy? That is just another application operations has to maintain and more fragile systems that can go down and break my automation. Even if I run it headless, it won’t get updated like a maven pom file pulling latest would.  The OWASP site points to sourceforge (https://code.google.com/p/zaproxy/wiki/ApiDetails ) for the client API and points to a rather outdated https://code.google.com/p/zap-maven-plugin/ (last updated in 2013) for the maven version.  Is that right?

Why can’t I just say "ZAP code, go scan this site, with this user, knowing that the login page looks like x, and logout looks like?" in a fluent API without having to use a client-server? I suppose I could pull the entire ZAP repo, but that seems heavy handed and will not provide updates. Then there is the APIs I have which all use HTTP which means at least part of the attack surface is the same as what ZAP covers. I admit I have not investigate this yet, but it seems like ZAP is mostly around web-based applications. With an API it seems like I could at least use the fuzzers built into ZAP. Again, an API seems more useful than a client-server system in my use case.

Am I missing something here? Am I misguided in what I am looking for? Am I an odd use case? I really do appreciate all the work you have done here. I realize maybe I’m an edge case or I have totally missed some important data, but even then I hope my feedback is useful.  Thanks,

- JCD

[Simon Bennetts]

Hi JCD, replies inline

On Tuesday, 17 February 2015 02:17:12 UTC, JCD wrote:

Let me start with a little context. I am a QA engineer who specializes in automation and from a skill set has the ability to do development work. We have several hundred Selenium tests, but the majority of our testing is around the our APIs. We have mod-security which blocks most attacks before they can even begin. Our application also locks out attacks around bad credentials and uses anti-CSRF measures. Currently we have mod security disabled in the QA environment while I play with ZAP. Ultimately what I think we would like to do is have some sort of nightly automated security testing occur around the web application and possibly around the APIs.

Sounds reasonable, and hopefully ZAP should fit in there nicely.
 

While using ZAP I have found a large set of options and lots of hard to understand data. For instance, the Active Scan tab shows all the various URLs hit but doesn’t show WHAT the tool was trying to test. SQL Injection? XXS? I can’t tell. I try right clicking the grid, but no options seem useful. After several days of working through ZAP and watching youtube videos (thanks Simon Bennetts and others…) I have gotten a scan which scan our entire site, but now if I right click on my login page and choose ‘flag as context’->1 it no longer shows a list of contexts. Awesome.  Maybe it is because I set my entire site to the context, but how do I get back to the context UI now?

Right now we dont show which rules are responsible for which requests, and you're the first person to ask for that (as far as I can recall).
Can you explain why you want to know that?
Its not that I dont think you need to know, rather I can think of many reasons and it would be helpful to know which one it is as there may be different approaches to getting this info.
For a start, you can use the Scan Progress dialog - this shows the rule currently being run.
You could also run a rule independently to see exactly what it was doing.

The contexts are all available via the Session Properties dialog.
We realise that this isnt that obvious, and if you try one of the recent weekly releases then you'll see that we now include the Contexts in the Sites tree - double clicking on the relevant context will bring up the Session Propertied dialog with the relevant top level context panel shown.
 

Really what I want is to not have the UI at all. Ultimately I want a nightly run with no human involved outside of review the results if they change. So I go looking for the Java version of the client software. Hrmm… No up to date maven repo. I guess I can put it in our local repo, but updates won’t get pushed to us nor can I automatically download the source code and documentation. Now that I have it in my repo, it seems to ultimately want to go talking back to the UI. This isn’t terrible, but why can’t I configure ZAP via an API and just run it by an API. Why do I need a ZAP UI application running somewhere in our VM farm playing proxy? That is just another application operations has to maintain and more fragile systems that can go down and break my automation. Even if I run it headless, it won’t get updated like a maven pom file pulling latest would.  The OWASP site points to sourceforge (https://code.google.com/p/zaproxy/wiki/ApiDetails ) for the client API and points to a rather outdated https://code.google.com/p/zap-maven-plugin/ (last updated in 2013) for the maven version.  Is that right?

We are in the process of 'mavenizing' ZAP. I'm afraid theres no 'release' date yet as we're focussing on getting ZAP 2.4.0 out at the end of this month.
But we want to migrate to GitHub and Mavenizing ZAP is a prerequisite for that.
We do have Docker images, both stable and weekly: https://code.google.com/p/zaproxy/wiki/Docker

If you run ZAP with the -daemon option then it will run headlessly - then the only way to interact with it is via the API. So you dont need the UI at all.
 

Why can’t I just say "ZAP code, go scan this site, with this user, knowing that the login page looks like x, and logout looks like?" in a fluent API without having to use a client-server? I suppose I could pull the entire ZAP repo, but that seems heavy handed and will not provide updates. Then there is the APIs I have which all use HTTP which means at least part of the attack surface is the same as what ZAP covers. I admit I have not investigate this yet, but it seems like ZAP is mostly around web-based applications. With an API it seems like I could at least use the fuzzers built into ZAP. Again, an API seems more useful than a client-server system in my use case.

So you can say those things via the REST API.
I'm guessing that isnt fluent enough ;)
Can you give an example of how you would like the API to look?

ZAP has very powerful scripting support - the scripts can access all of the ZAP internals.
One option would be to invoke ZAP with a script that invokes the internal calls which the API uses.

ZAP will attack API endpoints as long as it knows about them - discovery is key.
We have an add-on that allows you to import a WSDL or you can just proxy example API calls through ZAP.
 

Am I missing something here? Am I misguided in what I am looking for? Am I an odd use case? I really do appreciate all the work you have done here. I realize maybe I’m an edge case or I have totally missed some important data, but even then I hope my feedback is useful.  Thanks,

ZAP is designed for finding vulnerabilities in web applications. If thats what you're looking for then theres a very good chance that ZAP will do what you want.
I cant guarantee it will do everything, or that it will be as easy as you want.
But we always want to make ZAP better and easier to use, and we rely on feedback from users to help us make that happen :)

Cheers,

Simon
 

- JCD

[JCD]

Hi Simon,

Thanks for the reply.  I'll quote the relevant sections to not inline too deeply.

Right now we dont show which rules are responsible for which requests, and you're the first person to ask for that (as far as I can recall).

Can you explain why you want to know that?

Its not that I dont think you need to know, rather I can think of many reasons and it would be helpful to know which one it is as there may be different approaches to getting this info.

For a start, you can use the Scan Progress dialog - this shows the rule currently being run.

You could also run a rule independently to see exactly what it was doing.

Let's say I see a URL that is 'odd' in that I don't know how it was generated.  I see the referrer in the request header.  That is useful, at least now I know where that URL was found and hit, but I don't know HOW or WHY it got where it did.  If it doesn't trigger an existing rule for a failure, I can't see that data.  Furthermore, I might want to sort by the rule set just to scan through each rule just to discover what each rule does.  I guess I could just wait around while it is testing or select each rule to do the discovery, but that seems more labor intensive on my part.  It seemed sort of obvious that the grid would have a column picker and that I could add in that data, but no such thing exists.

If you run ZAP with the -daemon option then it will run headlessly - then the only way to interact with it is via the API. So you dont need the UI at all.

I think I was unclear.

* The UI code comes with the system, even if you don't run with the UI.

* The UI code doesn't provide an automatic update like you would get with maven.

* The UI code requires you to communicate via HTTP rather than being part of the language

* The UI code cannot be easily debugged because you are going over HTTP.

You are still required to keep the UI code.  The UI build on my box shows a 300MB file (or so) and that would not be ideal to check in.  The alternative is to have the UI (running headless) on some other box.  Either case that would require having someone maintain that system and update the system.  While the Client API (basically a REST API) can be mavenized, how does the server ('UI' or engine) get mavenized?  Does that make more sense?  I'm talking about the design of the system and how it gets maintained, not the fact that a GUI is displayed.

So you can say those things via the REST API.

I'm guessing that isnt fluent enough ;)

Can you give an example of how you would like the API to look?

By Fluent, I mean i terms of Martin Fowler used, http://en.wikipedia.org/wiki/Fluent_interface#Java

I would imagine having something like this:

new Zap().setSiteUrl(site).setContexts(

   new FluentList<Context>()

        .add(new Context().setEmailAndPasswords(mapOfEmailAndPasswords).setLoginRegex(regex).setLogoutRegex(logOutRegex))

   ).spider();

I could even see a simplified:

SpiderResults results = new Zap().loadSession(filePathToSession).setSiteUrl(siteUrl).spider();

results.attack();

I might be simplifying things a little, but that is roughly how I imagined it to work.  

ZAP has very powerful scripting support - the scripts can access all of the ZAP internals. One option would be to invoke ZAP with a script that invokes the internal calls which the API uses.

I realize this is not how it is currently done and perhaps that is a more developer-oriented view of how things would be done.  Having a scripting language doesn't work around the idea that you now have external dependencies outside of the automated code.  That makes automation more brittle.  I want to have my dependencies as near to the code as possible, without the need to have HTTP calls to an external system not managed by the build system.  While fluent isn't a requirement, it seemed like that would have been a reasonable way to handle newing up a complex object.  I don't expect this to be magically done tomorrow (or ever), but I thought it might be helpful feedback.

- JCD

[Simon Bennetts]

Replies inline:

On Wednesday, 18 February 2015 19:37:01 UTC, JCD wrote:

Hi Simon,

Thanks for the reply.  I'll quote the relevant sections to not inline too deeply.

Right now we dont show which rules are responsible for which requests, and you're the first person to ask for that (as far as I can recall).

Can you explain why you want to know that?

Its not that I dont think you need to know, rather I can think of many reasons and it would be helpful to know which one it is as there may be different approaches to getting this info.

For a start, you can use the Scan Progress dialog - this shows the rule currently being run.

You could also run a rule independently to see exactly what it was doing.

Let's say I see a URL that is 'odd' in that I don't know how it was generated.  I see the referrer in the request header.  That is useful, at least now I know where that URL was found and hit, but I don't know HOW or WHY it got where it did.  If it doesn't trigger an existing rule for a failure, I can't see that data.  Furthermore, I might want to sort by the rule set just to scan through each rule just to discover what each rule does.  I guess I could just wait around while it is testing or select each rule to do the discovery, but that seems more labor intensive on my part.  It seemed sort of obvious that the grid would have a column picker and that I could add in that data, but no such thing exists.

Maybe obvious, but no ones asked for that before.
Raise an Enhancement request for it :)
 

If you run ZAP with the -daemon option then it will run headlessly - then the only way to interact with it is via the API. So you dont need the UI at all.

I think I was unclear.

* The UI code comes with the system, even if you don't run with the UI.

Thats true.
We are looking at splitting up the code, but that wont happen for a while.
 

* The UI code doesn't provide an automatic update like you would get with maven.

ZAP has a 'check for updates' feature which checks both the core ZAP version and the versions of all of the add-ons you have installed.
There are options to either tell you about updates or automatically install them.
These are available via the API as well.
As all of the scan rules are in add-ons you can configure a headless ZAP to automatically download and install the very latest rules before is runs any tests.

 

* The UI code requires you to communicate via HTTP rather than being part of the language

* The UI code cannot be easily debugged because you are going over HTTP.

The UI is in Java swing.
The API UI is just a means of exploring the REST API, essentially a way of documenting the API. Its for manual exploring, we dont expect automated tools to use the API UI.
 

You are still required to keep the UI code.  The UI build on my box shows a 300MB file (or so) and that would not be ideal to check in.  The alternative is to have the UI (running headless) on some other box.  Either case that would require having someone maintain that system and update the system.  While the Client API (basically a REST API) can be mavenized, how does the server ('UI' or engine) get mavenized?  Does that make more sense?  I'm talking about the design of the system and how it gets maintained, not the fact that a GUI is displayed.

The plan is to completely mavenize ZAP, and that includes the core, the add-ons and the client libraries.
 

So you can say those things via the REST API.

I'm guessing that isnt fluent enough ;)

Can you give an example of how you would like the API to look?

By Fluent, I mean i terms of Martin Fowler used, http://en.wikipedia.org/wiki/Fluent_interface#Java

I would imagine having something like this:

new Zap().setSiteUrl(site).setContexts(

   new FluentList<Context>()

        .add(new Context().setEmailAndPasswords(mapOfEmailAndPasswords).setLoginRegex(regex).setLogoutRegex(logOutRegex))

   ).spider();

I could even see a simplified:

SpiderResults results = new Zap().loadSession(filePathToSession).setSiteUrl(siteUrl).spider();

results.attack();

I might be simplifying things a little, but that is roughly how I imagined it to work.  

It sounds like you want a Java security library.
ZAP has grown out of a desktop security tool (Paros) that was just designed to be interacted with via a Swing UI.
We added the API and now this has become the way many people interact with ZAP in a technology independent way.
I'm not aware of anyone else asking for a Java interface similar to the one youre asking for.
Question for other people on this list - anyone else want this?
Right now we dont have any plans for this, especially as it would be tied to just one technology (Java).
If anyone else is interested in working on something like this then I'd be delighted to provide advice and guidance, but I cant see myself working directly on it.
 

ZAP has very powerful scripting support - the scripts can access all of the ZAP internals. One option would be to invoke ZAP with a script that invokes the internal calls which the API uses.

I realize this is not how it is currently done and perhaps that is a more developer-oriented view of how things would be done.  Having a scripting language doesn't work around the idea that you now have external dependencies outside of the automated code.  That makes automation more brittle.  I want to have my dependencies as near to the code as possible, without the need to have HTTP calls to an external system not managed by the build system.  While fluent isn't a requirement, it seemed like that would have been a reasonable way to handle newing up a complex object.  I don't expect this to be magically done tomorrow (or ever), but I thought it might be helpful feedback.

As above - anyone else think this would be useful?

Cheers,

Simon
 

[Saurabh Seth]

Hi Simon

I have recently started using ZAP and have kind of similar requirements as to what JCD has. Can you give me an example of using the ZAP UI API which can do the following task?

1. Do an Spider and active scan on a host but run only on the 1st child pages and save the report in a given file.

Thanks

Saurabh

[gmaran23]

Hi,

Since you have mentioned you need to use the ZAP API ( i am assuming that's what you mean by ZAP UI API), there's some sample scripts that I could point you to that does spidering, active scanning on a host and writes a report.

ZAP API can be consumed easily by readily available API clients.

If you are a python expert: 

https://github.com/zaproxy/zap-api-python/blob/master/src/examples/basic-spider-scan.py 

For Java:

https://github.com/zaproxy/zap-api-java/blob/develop/subprojects/zap-clientapi/src/examples/java/org/zaproxy/clientapi/examples/SimpleExample.java

For DotNet:

https://github.com/zaproxy/zap-api-dotnet/blob/master/src/OWASPZAPDotNetAPI/OWASPZAPDotNetAPI.Samples/SimplePointAndClickScan.cs