1. Introduction
When implementing web services it's easy to forget handling of values that you don't expect, especially if input is restricted already on client side. The Invalid Types Scan is designed to help you to make sure that your server handles these kind of situations gracefully.
1.1. Typical real-world attack
By throwing values that are designed to cause unexpected behavior at web service operations, attackers might get the target server to give them useful system information (typically via error messages or stacktraces).
1.2. What it does
The Invalid Types Security Scan replaces the TestStep's original parameters with a number of values for the parameters that are designed to be invalid.
Note that unconstrained parameters will keep their original values.
2. Usage
Start by specifying which parameters to provide values for by using the Add, Remove, Copy, Clone and Extract all buttons. 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 that checks if the invalid boundaries that were sent caused the server to misbehave. Some assertions that would typically make sense for the Malformed XML is:
- Sensitive Information Exposure, to make sure that no server internals are exposed (e.g. via stacktraces if the server crashes).
- Schema Compliance, to make sure that the server response is not malformed.
These assertions are added/suggested automatically if the Security Test is generated by the Security Test Wizard in ReadyAPI.
2.1. Configuration
The Strategy tab lets you configure how soapUI should combine testing illegal values on multiple parameters and how long it should wait between each request:
- The One by One strategy iteratively tests an illegal value for each selected parameter, leaving all parameters but the currently tested at their original value.
- The All at Once strategy applies illegal value to all selected parameters at once.