Results of passive scan not adding to report or alerts
Closed this issue · 3 comments
Zap-cli has been showing some odd behavior when I to view the results thus far of a passive scan. I set zap-cli to passive scan on url 127.0.0.1 and port 8080, and then had firefox proxy through this but when I run zap-cli zap-cli alerts -l Low -f json it returns empty brackets. When I run zap-cli report -o report.xml it returns a file like this:
<?xml version="1.0"?><OWASPZAPReport version="2.7.0" generated="Wed, 6 Jun 2018 17:59:43"> <site name="http://example.com" host="example.com" port="80" ssl="false"><alerts></alerts></site><site name="http://ocsp.digicert.com" host="ocsp.digicert.com" port="80" ssl="false"><alerts></alerts></site><site name="http://pagead2.googlesyndication.com" host="pagead2.googlesyndication.com" port="80" ssl="false"><alerts></alerts></site><site name="http://platform.twitter.com" host="platform.twitter.com" port="80" ssl="false"><alerts></alerts></site><site name="http://m.addthisedge.com" host="m.addthisedge.com" port="80" ssl="false"><alerts></alerts></site><site name="http://m.addthis.com" host="m.addthis.com" port="80" ssl="false"><alerts></alerts></site><site name="http://randomcolour.com" host="randomcolour.com" port="80" ssl="false"><alerts></alerts></site><site name="http://www.theuselessweb.com" host="www.theuselessweb.com" port="80" ssl="false"><alerts></alerts></site><site name="http://s7.addthis.com" host="s7.addthis.com" port="80" ssl="false"><alerts></alerts></site><site name="http://www.ismycomputeron.com" host="www.ismycomputeron.com" port="80" ssl="false"><alerts></alerts></site><site name="http://redscientist.com" host="redscientist.com" port="80" ssl="false"><alerts></alerts></site></OWASPZAPReport>
All the websites I've been visiting are listed, but no vulnerabilities.
What's even more odd is that I've tried troubleshooting this and I've gotten the correct output from alerts but only after a significant amount of time. In one case I used the alerts and reports function (but nothing else) a few times for a half an hour and they weren't returning what I wanted them to. I then left my computer for another half an hour and came back and then ran the alerts command I mentioned earlier. It gave the passive scan results I wanted on all the websites I had visited in the hour I had it open the first time I ran it. The data for the vulnerabilities is definitely there but something seems to be holding it up, and I'm not sure what it is or how I'm eventually getting the report I want other than waiting long enough. Active scan and quick scan results are added to the report immediately, but passive scan results seem to be held up by something or sometimes not display at all.
That is odd, though it seems like it would be unlikely to be specific to zap-cli as it just calls the ZAP API to get that data, so I'd assume the issue is in ZAP or the ZAP API. Do the alerts show instantly if you open the ZAP GUI and view them there while browsing the site while proxied through ZAP? And if they do, do they show up with zap-cli alerts -l Informational -f json then?
I ran the API as you said and it brought the results up fine when I ran the alerts command in the client. Turns out that one of the websites I was running in the passive scan, redscientist.com, sends a lot of requests via it's global chat box. If you run the zap-cli without the GUI and you have this website up from the moment it starts, zap-cli seems to be unable to generate reports. Maybe it's getting overwhelmed, I'm not sure, but if I run from the daemon and don't have that website open it takes a few seconds to start being able to generate reports but other than that it works fine. This may just be a fringe case you don't really have to worry about.
That is strange since zap-cli just makes calls to the ZAP API. If you open the ZAP GUI, and run zap-cli commands while the GUI is open and it works, it should really work when you run ZAP as a daemon. Unless there are any memory issues in ZAP when it's run as a daemon, if as you said, ZAP might get overwhelmed temporarily while handling that many requests. If so, that seems more likely to be an issue in ZAP itself, rather than anything we can do to improve the situation in zap-cli.