Skip to main content

Fuzzer

io.resttestgen.implementation.fuzzer;

A fuzzer is an automatic testing tool that injects random or mutated input into a system to detect errors, vulnerabilities or unexpected behaviour.

Error Fuzzer​

This class generates mutant test sequences by applying changes to the parameters of API requests to test their robustness and error handling capability. The aim is to simulate erroneous inputs to test the API's error handling. Mutations are applied to request parameters to generate variants with missing values, wrong types or violated constraints. Finally, mutated sequences are executed and evaluated to test the behaviour of the API in abnormal scenarios. The operation of the Fuzzer is explained below. First, a test sequence is passed in to be modified. Mutators are defined (e.g. MissingrequiredParameterMutator, WrongTypeParameterMutator, ConstraintViolationParameterMutator). After that, mutated sequences are generated and, for each interaction of the original sequence, n variants are created. An applicable mutator is randomly selected and this new interaction is created and executed by a TestRunner. The report is also written using ReportWriter and RestAssuredWriter.

Mass Assignment Fuzzer​

This fuzzer deals with generating sequences to check the vulnerability of mass assignments. This class accepts an object of type CrudGroup that contains a set of CRUD operations on an object. These operations are divided into distinct sets. The “producer”, “consumer” and “read-only” parameters are identified (i.e. they are returned by read operations but are never modified). After that, test sequences are generated to inject the parameters into CRUD operations. These sequences test how a REST API handles mass assignment and may include attempts to modify parameters that should not be modifiable. A significant part of the class is devoted to generating test sequences for injecting parameters into creation operations. These sequences are executed on various read-only parameters and try to see if the application can be affected by modifying parameters that should not be modifiable. Within this fuzzer, you can also find the generateUpdateInjectionSequence method, which generates test sequences that test for vulnerabilities in the handling of update parameters by combining create, read and update operations in a sequence. In this case, for each read-only parameter, a sequence is created whereby a resource is created, its parameters are read, and finally an update operation is performed that attempts to inject an unscheduled parameter into the update process.

Nominal Fuzzer​

This fuzzer is designed to generate nominal test sequences for interaction with a REST API. The main purpose of this class is to create test sequences that simulate different input scenarios to test the behavior of an operation. The generateTestSequence() method generates a single test sequence. First, the original operation is cloned into an “editableOperation”. Let us look in detail at the various methods used to value the parameters:

  • setValue(Parameter parameter): sets the value of a parameter. If the parameter is of type LeafParameter (a parameter that has no children), it sets the value using the value provider. If the parameter is an array of LeafParameters, set the value for each element of the array.
  • populateArrays(): fills the arrays in the operation with copies of the reference elements. Each array has a minimum and maximum number of elements that may be added. If an array is not mandatory, there is a probability of removing it completely.
  • setValuesToLeaves(): assigns a value to parameters of type LeafParameter. If the parameter is not mandatory, it has a 10% chance of not receiving a value. In addition, it handles leaf parameters that belong to an array differently.

Subsequence Error Fuzzer​

This class is designed to generate test sequences that simulate errors in sub-sequences of an existing test sequence. Unlike other fuzzers, this class takes an existing test sequence, chooses a sub-sequence and corrupts it, applying mutations to the operation parameters it contains.

The original test sequence is divided into sub-sequences of increasing size. It starts at a length of 1, up to the length of the original sequence. For each sub-sequence, a copy is created, and mutations are applied. Each mutation is applied to the last element of the sub-sequence (i.e. last interaction). For each LeafParameter in the operation, a mutator is chosen that can be applied to the parameter. Once the mutation has been applied, the test sequence is executed with TestRunner, which simulates the execution of the operation with the mutation applied. The ErrorStatusCodeOracle is used to check whether the expected error occurs during the execution of the sequence, i.e. whether the test sequence produces the expected error status code for a given mutation type.