Integrating a new web services Framework for Frameworks handler with the existing Web Service Description Language custom scanner

About this task

When scanning a JAX-RS or JAX-WS application with AppScan® Source, you should ensure that you can capture all web service entry points so that you do not miss any vulnerabilities in your application. This document describes a technique for doing this. It outlines the steps that you would take to integrate a new Framework for Frameworks (F4F) handler that is used to analyze unsupported web service frameworks with the Web Service Description Language (WSDL) custom scanner.

This work is necessary so that the WSDL custom scanner will be able to differentiate between those web service entry points that have already been discovered by this new F4F handler and those web service entry points that exist in the WSDL file. With this information, the WSDL custom scanner will eliminate configuration findings that have already been analyzed by this new F4F handler.

Connecting the Web Service F4F handler to the WSDL Custom Scanner
Signature mapping

Connecting the Web Service F4F handler to the WSDL Custom Scanner

Before you begin

This section assumes that the main F4F handler and synthetic method generation have already been developed and tested.

Procedure

Add a dependency from your plug-in to com.ibm.appscan.frameworks.wsdl.util, which includes Helper APIs for reporting the services found. It also exists inside the walalib folder.
In the main handler (which extends the F4FHandler class), at the beginning of the handleApp() method, add these lines:
```
String filePath = WSDLReportingUtil.getServicesFilePath
     (getFrameworksInput().getFileLocs());
if (filePath!=null) {
WSDLReportingUtil.initXmlDocument(filePath);
}
```
These lines create a temporary file that will be used by the Custom WSDL Scanner.
At the end of the handleApp() method, add this line to ensure that all of the reported services are saved before the F4F Handler exits:
```
WSDLReportingUtil.saveXmlDocument();
```
To report a service, add a call to one of these APIs from the WSDLReportingUtil API:
- reportService(String targetNameSpace, String serviceName, String methodSignature)
- reportService(String targetNamespace, String serviceName, String operationName, ArrayList<String> wsdlParams)
where:
- targetNameSpace is the target name space of the service. In JAX-WS, for example, it is found in the annotations or match the package name.
- serviceName is the name of the service. This can be found in the annotations or it may match the service class name.
- methodSignature is the signature of the method from the WSDL file with some simplification.
- operationName is the name of the method, which is linked to a name of operation in one Port Type in the WSDL file.
- wsdlParams is the list of parameter types in simple WSDL format.
Currently the Custom WSDL Scanner works either as a stand-alone scanner or as part of a Java/JSP scan. If the new F4F Web Service Handler is designed to work with a language other than Java™ (for example, .NET), make sure that the WSDL Custom Scanner is called with the proper scan type by following these steps:
1. Go to the <data_dir>/ltd directory (where <data_dir> is the location of your AppScan Source program data, as described in Installation and user data file locations).
2. Make a backup copy of all files, to prevent any unexpected problems.
3. Open the .ltd file corresponding to the proper scan type. For example, for C++, open the cpp.ltd file.
4. Add this line before the closing <LanguageTypeDefinition> tag:
```
<Scanner name="wsdl"/>
```
5. Copy the file_extention_set_name value, which will be required for the next step.
6. Open file_extensions.xml and locate the FileExtensionSet that has the name that was copied in the previous step.
7. Add this line at that point in the file:
```
<FileExtension extension="wsdl" assess="true"/>
```
8. Save all files and restart AppScan Source. The WSDL Custom Scanner will now run as part of the full application scan.

Results

At this point, the WSDL custom scanner will only show configuration findings (in the Findings view) from WSDL files that are not implemented by your framework. Any services from WSDL files that are already implemented in the application will not show up as a configuration finding. These will be analyzed by the new web services F4F handler.

Signature mapping

About this task

The WSDL custom scanner will try to match the reported methods with the corresponding WSDL Services, WSDL Port Types, and WSDL Operations. This is why the web services are reported in WSDL format. Some simplifications have been added to make things easier to understand:

For any XSD primitive types, there is no need to add the target namespace. Instead, just use the name (for example, string, int, float, double).
For collections and arrays, [] is added after the type (for example, string[], int[]).
For class types that will be mapped to XSD complex types (using JAX-B or any other technologies), the type will appear such as this:
```
http//my-types/myxsdnamespace/:Customer
```
The namespace should be available as part of the Java annotation. If it is not part of the Java annotation, it should match the caller service namespace or the package name, depending on the implementation of the framework.

Note: Mapping errors will most likely prevent the WSDL custom scanner from matching your reported web service API with the associated WSDL operation. If this occurs, an extra configuration finding will appear. This extra finding should be considered a false positive and indicative of a mapping problem.

If you are not sure how the expected signature should look, run a WSDL scan from AppScan Source on the WSDL files themselves. This will generate findings for all operations under the WSDL services. Clicking on each finding will display the method signature in the Findings Detail view.