ZAProxy DEBUG statements can be configured using a environment variable
ZAProxy occasionally errors when running. Common errors include parsing errors when crawling URLs and heap space errors when the Java Heap has exhausted its allocation.
As the DAST runs in a separate process to the ZAProxy server, the feedback provided in the log file is not always useful. Occasionally, it is helpful to run either specific classes in DEBUG mode to output more information about the problem at hand.
The current workaround for this is to either:
- Map a volume to the DAST Docker container, overwriting the log4j.properties. This is difficult because volume mapping is not natively supported in GitLab CI config at this time (see gitlab-runner#3207). Users either must run docker-in-docker and start the container themselves, or perform the mapping using a GitLab runner configuration and make the runner specific to the DAST CI job.
- Check out DAST, modify the log4j.properties (or use the provided debug config), rebuild DAST and use it as the image in the build. This is not ideal because DAST must be built again. Not only is this non-trivial, but it results in a different DAST, which may come with completely different issues to those the user already has.
- Build a new image using DAST as the base image, and overwrite the log4j.properties. This is a non-trivial exercise.
Proposal
- A new environment variable
DAST_ZAP_LOG_CONFIGURATION
is supported - The value of the variable are log4j statements, e.g.
log4j.logger.org.parosproxy.paros.network.HttpSender=DEBUG
- More than one configuration can be specified by separating them with a comma
,
- The user can specify a value to make everything log using DEBUG
- Each value specified is appended to the log4j.properties before ZAP is started
- Subsequent runs of ZAP do not use log4j statements from previous runs