SOAP Parameter DOS

From WS-Attacks
(Redirected from Parameter Tampering)
Jump to navigation Jump to search

Attack description

Usually each SOAP request contains some sort of parameter that is passed to the application logic. If the application logic doesn't check what type of parameters are passed a classical buffer overflow within the application logic can easily occur if the parameters are out of bound. A simple example is a string value whose range of values is exceeded.

NOTE: This attack is not web application specific. All applications processing user input might be vulnerable to this attack. However it was added to show how to perform input validation for web service applications as described in "Attack mitigation / countermeasures".

This attack is also known as Parameter Tampering attack.

Attack subtypes

There are no attack subtypes for this attack.

Prerequisites for attack

In order for this attack to work the attack has to have knowledge about the following things:

  1. Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
  2. Attacker knows what parameters are expected by the application logic.
  3. Attacker can reach endpoint from its location. Access to the attacked web service is required. If the web service is only available to users within a certain network of a company the attack is limited.

Graphic representation of attack

AttackedComponent Application.png

  • Red = attacked web service component
  • Black = location of attacker
  • Blue = web service component not directly involved in attack.

Attack example

Let us assume that the attacked web service expects an integer value between 0 to 15. Which equals a variable size of 4 bits. If an attacker passes an integer smaller than 0 or greater than 15 a buffer overflow will occur if the application logic does not handle this exception. In Listing 1, the passed value is 20.

<?xml version=”1.0” encoding=”UTF-8”?>
<soap:Envelope xmlns:soap=”” xmlns:ns=””>

Listing 2: Attack example "XML Namespace Prefix Attack"

Attack mitigation / countermeasures

Every application - no matter from what source the data is coming - has to perform strict input validation. Web service applications are no different. However since web service requests are processed in stages the attack can be detected very early during strict schema validation. Using strict schema validation for input validation has the advantage that - if an attack was detected - other stages such as signature verification or decryption do not get processed; saving system resources by avoiding unnecessary resource intensive public key operations.

NOTE: Just because user input passed schema validation doesn't mean that the data is 100% save. An attacker might have found other techniques such as Attack Obfuscation to hide the attack from schema validation. To be on the save side. Both schema validation and the application logic should validate the user input!

Listing 2 shows an excerpt of an XML Schema matching Listing 1. The type is restricted to "integer" and the value is limited to the domain 0 to 15.

<!-- excerpt XML Schema for a SOAP message with integer 0-15 -->
<xs:element name="Surname">
    <xs:restriction base="xs:integer">
      <xs:minLength value="0"/>
      <xs:maxLength value="15"/>

Listing 2: Excerpt of a XML Schema limiting the number of occurrences of the element and the string length of the value within the element tags.

Attack categorisation

Categorisation by violated security objective

The attack aims at exhausting the system resources, therefore it violates the security objective Availability.

Categorisation by number of involved parties

Categorisation by attacked component in web service architecture

Categorisation by attack spreading


  1. Leroy Metin Yaylacioglu. Business value einer web service firewall. Master’s thesis,Hochschule für Angewandte Wissenschaften Hamburg, 2008.