Automation Framework "monitor" job test proposal

Skip to first unread message


Aug 31, 2022, 8:45:45 AMAug 31
to OWASP ZAP Developer Group
I've been thinking about how to fail an Automation Framework plan early, for example if the authentication fails.

My plan is to create a new "monitor" type of job test.
It would be similar to the "stats" job test but instead of running after a job it would run _during_ a job.
It would only be supported by specific 'long running' jobs like the spider, spiderAjax, active scan etc

The config would include a statistic name and a threshold - if that threshold is exceeded at any point during the job then the job will fail. The action being performed (spider / active scan etc) will be stopped.
Whether or not the plan fails will depend on the plan config.

The idea is that this could then be used to check for things like auth failures and exit a job/plan early rather than potentially waiting hours for it to finish and then fail.

Any thoughts, suggestions or feedback?



Ananda Krishna

Sep 1, 2022, 4:30:47 AMSep 1
to OWASP ZAP Developer Group
This sounds like a good idea - we have something similar implemented. Have currently implemented such a threshold using global variables - and it works well in production across multiple sites.

Like you have suggested, would be great if we can specify in the plan config whether the plan should fail or continue scanning without trying to authenticate again. This would be a little more flexible, and allow the site to be scanned (although without authentication) as it would have normally done.

Currently when using script based auth (and selenium), and an incorrect auth script - ZAP retries auth multiple times in a span of few seconds causing the browser to respawn every time and hog resources.


Sep 2, 2022, 10:34:58 AMSep 2
to OWASP ZAP Developer Group
The PR for this enhancement is - feedback always appreciated :)

Right now theres no option to "continue scanning with no auth", partly because this is completely generic and works off any stats, and partly because that sort of feature would require core changes.
However I'm also wondering how useful it would actually be?
I would prefer to know that the authentication failed and that the job terminated.
Note that if you are using script based auth you can implement this in your scripts, which I think would be a cleaner approach...

Thoughts anyone?
Reply all
Reply to author
0 new messages