This guide assumes that you have set up your Web App fuzzing project, connected a webservice and created a fuzz test. Also you need a CI Fuzz server with a web interface, either in the form of SaaS subscription or installed on premises and you need to clone your fuzzing project in the web interface.
Decide Where You Will Run the SUT
If not already done, you now have to decide where the deployment of your web application under test should run.
There are basically 3 options:
On the CI/CD-server (gitlab/github/jenkins server)
On the CI-Fuzz server
A seperate server (e.g. your integration testing cluster)
As an example, we will run WebGoat in a docker container on the CI-Fuzz server. This gives the best performance, as the HTTP requests that contain fuzzing input will not be sent over a real network.
If you choose to run your application on another server, you need to make sure that:
- The application is exposed on a network interface and the port on which it is running is reachable from CI Fuzz server
- Ports 6773 and 6777-7777 on the CI Fuzz server are reachable by your application
Modify Java Agent command line
In the WebUI, go to “Web Service” and click “Add Web Service” and type in the SAME name you used when initially creating the web service in VS Code. Additionally, use “Use custom fuzzing server settings” and enter the domain of the CI Fuzz server (this is the same as the domain of this web UI)
We don’t really want to create a new web service, we only want to know the project name.
We will replace the project name in the locally generated java agent argument when building the image to run WebGoat on the CI Fuzz server
Generate a CI-Fuzz API token in the server web UI in the settings of your organization or your user settings (by clicking on your picture in the upper right corner)
Copy the Dockerfile and start script to the CI Fuzz server.Add additional options to the java agent command snippet:
- tls=true (required) Enable TLS. This option only applies to the communication between the fuzzing agent and ci-daemon. The gRPC communication between fuzzing agent and fuzzer is unencrypted!
- cert_file (optional) specify the location of the TLS certificate that is used by the CI Fuzz server. Only required if the cert is not signed by a public CA and the corresponding CA Root certificate is and not imported on the host where the Java Agent is running.
- api_token=<CI-Fuzz-server-token>: (required) The java agents needs to authenticate against the ci-daemon (the server)
- fuzzing_server_host: Use a host name that is listed in the server's TLS certificate, otherwise the TLS connection will fail.
You can find more java agent command options in the Set Java Agent Options article.
Running the Software Under Test
If needed, change the base_url in .code-intelligence/fuzz_targets/<fuzz_test_name>.yml to point to the deployment of your SUT you want to use for fuzzing. In our WebGoat example, we don't need to adjust it if we were exposing Webgoat on localhost,, as we can do the same thing on the server.
Run your application. WebGoat can be started the same way as we did locally:
docker run -it -v /opt/ci-fuzz-2.23.0/lib/code-intelligence/:/cibin/ -p 80:8888 -p 8080:8080 -p 9090:9090 -e TZ=Europe/Amsterdam webgoat_instrumented
If your DNS server maps the CI Fuzz's hostname to a reverse proxy or load balancer or such, then the communication from the Java Agent would have to go through that, which could lower performance or lead to problems with closed fuzzer ports. Use the --add-host docker option to make the Java Agent use the docker network interface instead:
docker run -it --add-host app.code-intelligence.com:172.17.0.1 -v /opt/ci-fuzz-2.23.0/lib/code-intelligence/:/cibin/ -p 80:8888 -p 8080:8080 -p 9090:9090 -e TZ=Europe/Amsterdam webgoat_instrumented
Replace app.code-intelligence.com with your hostname, and adjust your docker host IP if it is different.
Running the fuzz test
In the CI Fuzz Web Interface, click on your fuzz test, then run:
About fuzzing results, see Using the CI Fuzz Web Interface (last section).
For information about automating fuzzing in CI/CD, see Continuous Fuzzing Setup.