Invalid Types

PDF Print E-mail
User Rating:  / 4
Rate this article: PoorBest 

Invalid_Types

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 Boundary Check Security 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 out of the expected boundaries 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 Boundary Check Security Scan replaces the TestStep's original parameters with values violating the boundaries defined in the web service definition. Boundaries identified and violated are:

  • xsd:min
  • xsd:max
  • xsd:length
  • xsd:minInclusive
  • xsd:maxInclusive
  • xsd:minExclusive
  • xsd:maxExclusive
  • xsd:totalDigits
  • xsd:fractionDigits

Note that unconstrained parameters will keep their original values.

By using assertions, you can make sure that the server behaved as expected.

2. Usage

Start by specifying which parameters to perform boundary checking on by using the Add, Remove, Copy, Clone 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 5_snag_evi 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:

  • Schema Compliance, to make sure that the server response is not malformed.
  • Sensitive Information Exposure, to make sure that no server internals are exposed (e.g. via stacktraces if the server crashes).

These assertions are added/suggested automatically if the Security Test is generated by the Security Test Wizard in soapUI Pro.

2.1. Configuration

The Strategy tab 3_snag_evi 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.

3. Prevention & Further reading

Read more about Cross-site scripting and how to protect yourself at the following websites: