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.
NOTE: 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. Using a streaming based parser like SAX reduces the likelihood for the attack to succeed, since the entire document is never loaded in memory.
- 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.
Prerequisites for attack
In order for this attack to work the attacker has to have knowledge about the following things:
- Attacker knows endpoint of web service. otherwise he is not able to reach the web service.
- 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.
Graphical representation of attack
- Red = attacked web service component
- Black = location of attacker
- Blue = web service component not directly involved in attack.
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> ..
Listing 4: Excerpt of a XML Schema limiting the number of occurrences of the element and the string length of the value within the element tags.
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 by 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 .
It is understood that strict schema validation is resource intensive, however if well written it guarantees maximum security against the attack without artificially limiting the document size.
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
- Meiko Jensen, Nils Gruschka, and Ralph Herkenh ̈ner. A survey of attacks on web services. Springer-Verlag, 2009.
- Meiko Jensen.Attacking webservices.http://www.nds.rub.de/media/nds/downloads/ws0910/AttackingWebServices.pdf, 2010. Accessed 01 July 2010.
- 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
- Leroy Metin Yaylacioglu. Business value einer web service firewall. Master’s thesis,Hochschule für Angewandte Wissenschaften Hamburg, 2008.