Interface fuzzing, and specifically for this tutorial, Web Service fuzzing, differs from file, network or application fuzzing, in that Web Service fuzzing does not require a template or example of a Web Service method being called in order to generate test cases. Instead Fuzzware will try to automatically generate the parameters of the Web Service methods, however you can influence this generation. Another difference between Web Service fuzzing and the other types is that Fuzzware creates XSD files that follow a specific format, however rather than force people to learn that format, the majority of settings for Web Service fuzzing can be made through the UI. This format will be explained for completeness sake but this will only be relevant for those doing advanced fuzzing.

Rather than setup a Tutorial4 project, we will use the Examples\WSDL project in the Fuzzware projects directory that contains an example web service (in a Microsoft Visual Studio solution with source code). Open the WSDL project and select 'Configure the input source'.

Fuzzware requires a WSDL file describing the services and methods exposed by the Web Service. Typically there is only one WSDL or we would fuzz only one at a time, but Fuzzware does allow you to specify more than one and internally it combines them all into one large WSDL. If the WSDL file(s) does not compile correctly an error message will be presented indicating the problem. Many Web Services have services that work with more than one protocol, so the Web Service protocol must also be chosen.

If the WSDL(s) compile then you will be able to add to the list of Initial Methods, trying to do so brings up a list of methods to choose from. The ability to specify an initial method is important as some Web Services require their methods to be called in a certain order e.g. login, or load methods. Any methods that aren't specifically listed in the initial methods will be called in a random order for a given testcase. It is important to point out that Fuzzware will call all the methods in the WSDL for every testcase.

Try adding and removing Service1.wsdl and Service2.wsdl to see how the list of available Initial Methods changes depending on the WSDLs specified. Also note that the Initial Methods are prefixed by a service name so you can distinguish which methods belong to which service.

The last configuration section is the default method parameter values. Since Fuzzware does not use a template or example of the Web Service method calls, the parameters of the methods must be given. Rather than specify each method parameter individually, Fuzzware populates method parameters by their type, hence at the bottom of this section you can specify for example the default value of all parameters of type String. The last default parameter type is Variant, however this is not relevant for WSDL fuzzing.

Being able to choose the default value for all parameters is fine, but often we want to give specific parameters a certain value, or groups of parameters a certain value. Below we can see how this can be achieved by adding specific rules for Fuzzware to follow when it assigns parameters their values.

There are 4 rules to choose from:
1. Named method/parameter: From the dropdown lists choose a specific method (only those with input parameters are listed) and then choose a specific parameter and assign it a value. You can tell the type of the parameter because initially it will get the default value for that parameter type.
2. Any parameter name containing: Any parameter on any method that contains the specified string will be assigned the specified value. E.g. any parameter containing 'date' could be assigned a certain date.
3. Any parameter name starting with: Any parameter on any method that starts with the specified string will be assigned the specified value.
4. Any parameter name ending with: Any parameter on any method that ends with the specified string will be assigned the specified value.

Note also that these rules are applied in the order given (which can be changed), so they should be ordered least specific (e.g. any parameter containing 'a') to most specific (e.g. a specific method and parameter).

With the input source configured, now we can configure the corresponding output destination, 'Send testcases to Web Services'

Whilst Fuzzware does not require an example of WSDL method calls, nevertheless some web services use advanced or custom web service features that Fuzzware knows nothing about. Hence the first output destination configuration option tells Fuzzware what SOAP template file to use (the template is not an example of the Web Service we are fuzzing but instead a skeleton SOAP request that we will populate). There is a default SOAP template file that ships with Fuzzware (located in the Resources directory where Fuzzware is installed), that contains a basic template for a SOAP method request, however this can be copied and changed, all Fuzzware relies on is being able to append to the Body element of the SOAP request. Note also, that if a pre-output handler changes the template, Fuzzware will notice this and reload it from the file (it checks the modified time on the file).

The next configuration option is the reuse response values. Some web service methods will respond with a value that they expect to be included in subsequent requests; to accommodate for this you can specify the name of the response node to look for and Fuzzware will record its value, and if a subsequent request has a node with the same name, Fuzzware will replace its value. Fuzzware makes sure not to replace the value if the node that is currently the target of fuzzing is the node specified.

The final options is the output configuration were you can choose the output directory and file extensions of any saved test cases. So how does Fuzzware decide which test cases to save? Basically Fuzzware records the response to every method request, and if that response is unique then it will record the test case. This leads to a slight problem for Web Service fuzzing because there are usually multiple responses in the one test case, but Fuzzware overcomes this by recording the test case if any of the responses are unique and noting the method which caused the unique response in the output statistics (which is why the same state is listed more than once, but each state should have a unique method appended in brackets after it).

Advanced Configuration
Whilst the UI allows for some customisation, it does lack some convenience:
1. You cannot limit the methods that are called, all the methods of the WSDL will be called per test case.
2. The UI is not convenient if we need to specify a large number of default values for method parameters.

To overcome these limitations it is best to run your WSDL project in Test Mode and look at the output files in the project directory. Fuzzware creates XSD files containing the definitions of all the types in the WSDL and of the methods of the WSDL. Fuzzware also creates an XML file containing the methods it will call and the order in which it will call them. The key point about the files that Fuzzware generates is that if you run Fuzzware again, it will not overwrite these files if they are already exist, but will load these files and reuse them, hence they can be manually editted.

So both the above limitations can be solved by editing the XML directly; you can remove methods that you do not want to call and you can directly specify method parameter values in the XML. The format of the XML is very straight-forward with a root node that contains the SOAP Body method XML that will populate the SOAP template (specified in the output destination configuration), the only difference is the method names are pre-pended with the service name (so multiple services with methods of the same name can be distinguished). Note also that the XSD files can also be altered if Fuzzware has any issues with the types being used.