Found that dast image is running with root privileges. This can be checked running image in interactive mode:
root@7020cd870424:/output# id
uid=0(root) gid=0(root) groups=0(root)
As changed now the image is running with user zap:
zap@a1cd694150ba:/output$ id
uid=1000(zap) gid=1000(zap) groups=1000(zap)
Juan Pablo Perata (d0ae4a77) at 11 Jul 02:42
Fix docker image running with zap user instead of root
Excellent @dappelt! Thanks for the quick response and fix, verified ok.
Last Friday June, 14th I discovered that -g and -r arguments that came from ZAP Baseline and ZAP Full Scan are not recognized.
As far as I remember until this commit I had no problems at all.
Besides this was the image I was using locally, before pulling it again:
registry.gitlab.com/gitlab-org/security-products/dast b2547fa74a73 2 weeks ago 2.98GB
Today I ran dast against a dockerized WebGoat:
(registry.gitlab.com/gitlab-org/security-products/dast:latest, image ID 261377f77b51, sha256:812de719a44a037b81327463dda71acf5936b709c3f47bfd709d45d8be1644ca)
docker run --rm -v $(pwd):/zap/wrk/:rw -i registry.gitlab.com/gitlab-org/security-products/dast:latest /analyze -t "http://goat:8080/WebGoat" --auth-url "http://goat:8080/WebGoat/login" --auth-username "sample" --auth-password "sample" --auth-exclude-urls "http://goat:8080/WebGoat/logout" -g gen.conf -r testreport_webgoat.html
I only get gl-dast-report.json.
One more thing: If I execute zap-baseline.py or zap_baseline_original.py inside the docker image in interactive mode with -r there is no problem at all,
but ...
If I run /analyze -t "http://goat:8080/WebGoat" -r "report.html" a message is displayed:
-r: not found
Could it be that this latest commit on analyze file changed some of its initial behaviour?
Thanks for your reply @twoodham. Yes sure, I took this test shell script, changing the line for BUILT_IMAGE to:
BUILT_IMAGE=registry.gitlab.com/gitlab-org/security-products/dast
I attach zap.out log: zap.out as well the output of dast scan: gitlab.dast.stout
I also saw another warning in the log you will notice as well:
com.fasterxml.jackson.core.JsonParseException: Unexpected character ('/' (code 47)): maybe a (non-standard) comment? (not recognized as one since Feature 'ALLOW_COMMENTS' not enabled for parser)
While running DAST, I came up with this warning in zap.out file.
10830 [ZAP-ProxyThread-7] WARN org.zaproxy.zap.extension.api.API - Bad request to API endpoint [/JSON/context/action/setContextInScope/] from [127.0.0.1]:
Does Not Exist (does_not_exist) : Default Context
at org.zaproxy.zap.utils.ApiUtils.getContextByName(ApiUtils.java:189)
at org.zaproxy.zap.utils.ApiUtils.getContextByName(ApiUtils.java:174)
at org.zaproxy.zap.extension.api.ContextAPI.getContext(ContextAPI.java:367)
at org.zaproxy.zap.extension.api.ContextAPI.handleApiAction(ContextAPI.java:181)
at org.zaproxy.zap.extension.api.API.handleApiRequest(API.java:449)
at org.parosproxy.paros.core.proxy.ProxyThread.processHttp(ProxyThread.java:463)
at org.parosproxy.paros.core.proxy.ProxyThread.run(ProxyThread.java:320)
at java.lang.Thread.run(Thread.java:748)
That points out to a ZAP context that was not created before, as seen in this line of code: https://gitlab.com/gitlab-org/security-products/dast/blob/master/src/zap_webdriver.py#L65
Kind regards, Juan