XML Injection

Attack description

During an "XML Injection" an attacker tries to inject various XML Tags in the SOAP message aiming at modifing the XML structure. Usually an successful XML injection results in the execution of a restricted operation. Depending on the executed operation various security objectives might get violated. Typical examples are:

• modification of payment data -> violated security objective: Integrity
• unauthorised admin login -> violated security objective: Access Control

NOTE: Usually only web services using a DOM parser are susceptible to this attack. The DOM Parser creates an in-memory representation of the SOAP message. During this process the SOAP message size can raise by a factor of 2 to 30. When very large documents are processed memory exhaustion is often the result. When using a streaming based parser like SAX it is very unlikely for the attack to succeed, since the entire document is never loaded in memory. Only in very rare cases, depending on the implementation, SAX parsers are also susceptible to this attack. Refer to [1] for a detailed discussion.

A thorough description on how to test for XML Injection can be found in the OWASP guide [2].

Attack subtypes

There are no attack subtypes.

Prerequisites for attack

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

1. Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
2. Attacker knows metadata such as the WSDL file of web service.
3. Attacker can reach endpoint from its location. Access to the attacked web service server is possible for the attacker. This prerequisite is important if the web service is only available to users within a certain network.

Graphic representation of attack

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

Attack example

Lets consider an example from [3] Listing 1 shows a unmodified payment transaction.

..
<!-- excerpt unmodified SOAP message -->
<transaction>
   <total>4000.00<total>
   <credit_card_number>
      123456789
   </credit_card_number>
   <expiration>01012008</expiration>
</transaction>
..

Listing 1: unmodified payment transaction

Listing 2 shows a modified payment transaction. If the SOAP message gets executed the attacker has to pay only 6.66$ instead of 4000.00$

..
<!-- excerpt modified SOAP message -->
<!-- excerpt unmodified SOAP message -->
<transaction>
   <total>4000.00<total>
   <credit_card_number>
      <!-- Attack payload line below. If attack is executed succesful, the <total> tag with its value gets overwritten by 6.66 --> 
      123456789</credit_card_number><total>6.66</total><credit_card_number>123456789
   </credit_card_number>
   <expiration>01012008</expiration>
</transaction>
..

Listing 2: unmodified payment transaction

Attack mitigation / countermeasures

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 XML Schema for a SOAP message -->
<xs:element name="transaction">
  <xs:complexType>
    <xs:sequence>

      <xs:element name="Stotal">
        <xs:simpleType>
          <xs:restriction base="xs:float">
            <xs:minLength value="0"/>
            <xs:maxLength value="10"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
      <xs:element name="credit_card_number">
        <xs:simpleType>
          <xs:restriction base="xs:integer">
            <xs:minLength value="10"/>
            <xs:maxLength value="10"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
      <xs:element name="expiration">
        <xs:simpleType>
          <xs:restriction base="xs:integer">
            <xs:minLength value="8"/>
            <xs:maxLength value="8"/>
          </xs:restriction>
        </xs:simpleType>
      </xs:element>

    </xs:sequence>
  </xs:complexType>
</xs:element>
..

Listing 3: Excerpt of a XML Schema for Listing 2

By using the data type "string" only strings are allowed within the element tags. The <maxLength> tag limits the string length to 20 characters. The number of occurrences of the element "Surname" is limited to 1, since per default the maximum and minimum number of occurrences is 1. Any SOAP message that violates this schema is rejected. If no other tags are defined within the XML schema of the SOAP body any other tag is prohibited by default too, making it impossible to mount the attack.

For a more detailed tutorial on how to create a strict XML schema refer to [4].

It is understood that strict schema validation is resource intensive, however if well written it guarantees maximum security against the attack.

Note: Some might recommend the use of SAX Parser as a countermeasure. This strategy will work, but when moving to a new framework that uses a DOM based parser the web service will be vulnerable to the attack. That is why strict schema validation should always be performed.

Attack categorisation

Categorisation by violated security objective

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

• Category:Attack_Categorisation_By_Violated_Security_Objective_OTHER
• Category:Attack_Categorisation_By_Violated_Security_Objective

Categorisation by number of involved parties

• Category:Attack_Categorisation_By_Number_Of_Involved_Parties:1_-_0_-_1
• Category:Attack_Categorisation_By_Number_Of_Involved_Parties

Categorisation by attacked component in web service architecture

• Category:Attack_Categorisation_By_Attacked_Web_Service_Component:_XML_Parser
• Category:Attack_Categorisation_By_Attacked_Web_Service_Component

Categorisation by attack spreading

• Category:Attack_Categorisation_By_Attack_Spreading
• Category:Attack_Categorisation_By_Attack_Spreading:Application_Specific_Flaws

References

1. Meiko Jensen, Nils Gruschka, and Ralph Herkenh ̈ner. A survey of attacks on web services. Springer-Verlag, 2009.
2. Nishchal Bhalla and Sahba Kazerooni.Web services vulnerabilities.http://www.blackhat.com/presentations/bh-europe-07/Bhalla-Kazerooni/Whitepaper/bh-eu-07-bhalla-WP.pdf, February 2007. Accessed 01 July 2010.
3. Alex Stamos. Attacking web services. http://www.owasp.org/index.php/File:AppSec2005DC-Alex_Stamos-Attacking_Web_Services.ppt, October 2005. Slides OWASP AppSec DC 2005, Accessed 01 July 2010.
4. Leroy Metin Yaylacioglu. Business value einer web service firewall. Master’s thesis, Hochschule für Angewandte Wissenschaften Hamburg, 2008.
5. OWASP XML Injection testing guide [[5]]