Fuzzing Scan

Fuzzing Scan Reference

1. Introduction

The term "Fuzzing" has a broad meaning in the security-testing domain, but most commonly it is used to describe the practice of generating random input for a target system, for example by trigger random mouse and keyboard clicks for user interface or by creating totally random input data to some kind of system. By doing this repeatedly over a prolonged period of time, the fuzzing "attack" strives to uncover instabilities in the target system which are not uncovered by a more structured testing process.

What it does

The Fuzzing Scan does just as described above; it generates totally random input for the specified request parameters for a specified number of requests, hoping to provoke some kind of unexpected . By default the generated values will be between 5 and 15 characters in lenght and mutated 100 times; a more realistic fuzzing test might change these settings to be between 0 and 100 characters for 100000 requests. This might of course take some time, but will be more in the "spirit" of fuzzing. You can configure these values in the advanced configuration tab:

Fuzzing Scan Advanced Reference

2. Usage

Start by specifying which parameters to inject fuzzed vaues into by using the AddRemoveCopyClone and Extract all buttons 1_snag_evi. The Extract all button will extract all non-empty parameters from the tested request.

Then add assertions using the controls at the bottom of the window 3_snag_evi that checks if the injection succeeded. Some assertions that would typically make sense for the Fuzzing Security Scan is:

  • Sensitive Information Exposure, to make sure that the target system does not expose system internals when provoked with random input
  • Valid HTTP Status Codes, e.g. to assert that the request does not return a 5xx status code (Server Error).

These assertions will be added/suggested automatically if the Security Test is generated by the Security Test Wizard in ReadyAPI.

2.1. Configuration

The Strategy tab 4_snag_evi lets you configure the following:

  • The Request Delay to insert between each fuzzing request (to not overload the server)
  • If the Scan should be applied to a failed functional TestStep also
  • If the Scan should be run only once for the containing TestStep during the entire execution of the SecuritTest. This might be useful if the request is inside a DataSource Loop setup that runs the same request repeatedly.

3. Further reading

Read more about Parameter Fuzzing and Fuzz Testing at the following websites: