ZAP development policy related to using command line tools in passive rules

[Florencio Cano]

Hi!

I'm a long time ZAP user, but totally new to the development side of it. I have never contributed any code to ZAP and programming is not my main skill; I'm more a security guy.

I'm thinking about the possibility of implementing https://ian.sh/cookiemonster in ZAP. I have thought about a passive rule. I think it could be similar (e.g. structure) to this one: https://github.com/zaproxy/zap-extensions/blob/main/addOns/pscanrules/src/main/java/org/zaproxy/zap/extension/pscanrules/CookieSameSiteScanRule.java.

My doubt is that cookiemonster is a tool with its own development and complexity. Could I use it through the passive rule or should I implement its functionality in Java and for ZAP?

[psiinon]

Hiya,

Welcome to ZAP deveopment :D

ZAP _can_ call any tools from the command line, but there are "challenges" especially with scan rules.

First of all, its safe to assume that pretty much no ZAP user will have any specific tool installed, unless it is included with the OS.

Most ZAP users will also not install additional tools manually, so if your rule depends on a non standard tool then very few people will actually use it.

We can bundle 3rd party tools with ZAP or add-ons (depending on their license) but then we need to handle at least Linux, Windows and MacOs.

Search for the name "WebDriver" on https://www.zaproxy.org/addons/ to see an example of this.

Secondly, passive scan rules get invoked for every request/response - I havnt checked but I can imagine that invoking command line tools could well take significantly more time that we would typically want in this case.

All of this means that I cant see us accepting a passive scan rule into the zap-extensions repo if it depended on a command line tool.

You are of course very welcome to implement one in one of you own repos and we'd still be prepared to include it in the ZAP Marketplace, but I honestly wouldnt expect many people to really use it.

So, in this case I think reimplementing the functionality in Java would be the best option :)

Cheers,

Simon