Creating a Web Application Fuzz Test

To create a fuzz test for a Spring Boot application, go to the sidebar menu in the dashboard and click on the “Add Fuzz Test” button.

From the list, choose to create a Java Agent fuzz test.

After selecting it, you will be forwarded to the second step, where you can name the new fuzz test and specify which web services you want to test. In case of Webgoat, we only have one.

Exception Policies

We can leave these unticked, which will result in a reasonable default being used.

With exception policies, you define what kind of behavior is considered erroneous during the fuzz test. Imagine fuzzing an endpoint that returns information about a resource based on a given numerical id /resource/{id}/. This endpoint will respond to requests like /resource/1/, /resource/99/, /resource/1223/ etc. For a request like /resource/XYZ/, it would be appropriate for the application to throw an error of type 404, indicating that the server could not find the resource. Therefore, it is a good idea to ignore errors of type 404 for this fuzz target. Errors in the business logic (often declared as errors of type 500-511) should still be considered harmful.

In CI Fuzz, these kinds of settings are called exception policies. They can be set per project, per fuzz target, or as a combination of both.

 

By default, the automatically generated fuzz test will test all the endpoints detected during the analysis phase. If you’re more interested in testing selected endpoints, you can remove seed requests (explained later).

Click save, then run. After a few seconds, the status of the fuzz test should be running:

This assumes that your application is running on http://127.0.0.1:8080. If this is not the case, open the configuration file of your fuzz test in .code_intelligence/fuzz_targets:

Uncomment base_url and adjust it accordingly, then run the fuzz test.

After a few minutes, click on the fuzzing run:

3 unique corpus inputs means 3 unique code execution paths in the application. This is a very low number. It happened because the application rejects most request, as they are not authenticated.

Initial Requests

If your web application uses authentication, you can configure CI Fuzz to authenticate before it starts fuzzing. You can do this by defining the requests that have to be made to successfully log in to the application. Here you can find the different options to do this.

Here we can add a request to register a user and a login request, one below the other (Content-Length must be correct). Both will be sent before fuzzing starts, so we don't have to rely on the user already existing or not existing. Any cookie that the fuzzer receives in response will be then used during fuzzing.

Now we can run fuzzing again.

That's better!

For other authentication methods, see configure-http-headers.

Seed Requests

During the initialization, CI Fuzz scanned all the endpoints that your application offers. This scan allows us to identify the types of requests that are expected at every endpoint. This allows us to craft valid requests against the application's endpoints and fuzz only interesting parts of the requests (e.g., only parameter values, not parameter names). This smart fuzzing approach allows you to reach code deep inside your application's business logic. In case you want to modify or add new requests, you can modify the request templates (method, URI, headers, and body) for the selected fuzz test.

These can be found in .code_intelligence/<your fuzz test name>_seed_corpus directory.

The Host: header is ignored by CI Fuzz, but you can adjust it to test the requests by sending them, if you install the REST Client VS Code Extension.