XML Entity Reference Attack
- 1 Attack description
- 2 Attack subtypes
- 3 Prerequisites for attack
- 4 Graphical representation of attack
- 5 Attack example
- 6 Attack mitigation / countermeasures
- 7 Attack categorisation
- 8 References
The XML standard allows the use of DTDs (Document Type Definitions). DTDs are meant to define the legal building blocks of an XML document. One feature of DTDs are the ability to define entities. Entities are variables used to define shortcuts to strings or special characters. Typical examples of predefined entities are the entities used within HTML. When wanting to use the "<" or ">" character outside of HTML Tags they have to be replaced by their entities:
- the character ">" has the entity ">"
- the character "<" has the entity "<"
Entities that are not predefined can be declared internal or external.
- internal declaration - the entity is defined within the same document.
- external declaration - the entity is defined in an external document. Only the reference to the external document is given.
When included in a SOAP message, entities can be used to mount attacks retrieving data located on the attacked server.
NOTE: Since SOAP Version 1.2  external entities are not allowed within SOAP messages any more. However many web services don't implement the standard correctly, that is why they are still vulnerable to this attack. See  for more details: "The XML infoset of a SOAP message MUST NOT contain a document type declaration information item."
NOTE: XML Entity Reference Attacks attacks are a little different than XML Entity Expansion and XML External Entity DOSattacks. XML Entity Expansion and XML External Entity DOS attacks aim at exhausting the resources of the attacked web service. However XML External Entity Reference attacks try to disclose information. When the attack is carried out successfully sensitive data on the attacked server or network is exposed.
There are no attack subtypes for this attack.
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.
We take an example published by Security Compass  Lets assume we have an imaginary web service that lets you order products. When placing an order the following attributes have to be submitted:
- customer ID
- Customer name
- Credit card number
- Credit card expiry
- Product ID
Once the order is placed successfully the web service returns the following message:
Thank you [Customer name]. Your order has been placed.
Listing 1 shows an excerpt of a valid SOAP message placing an order.
<?xml version="1.0"?> <!DOCTYPE order SYSTEM "c:\order.dtd"> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/order"> <order> <cust_id>1</cust_id> <cust_name>Bob Smith</cust_name> <creditcardnum>999999999999</creditcardnum> <creditcardexpiry>0609</creditcardexpiry> <item> <prod_id>1</prod_id> <quantity>2</quantity> </item> </order> </soap:Body> </soap:Envelope>
Listing 1: Valid SOAP message
As expected the response is:
Thank you Bob Smith. Your order has been placed.
Now that we verified, that the content of [Customer name] is given back to us, we can request any file on the attacked server.
<?xml version="1.0"?> <!DOCTYPE order [ <!ELEMENT order ANY> <!ELEMENT cust_name ANY> <!ENTITY name SYSTEM “c:\boot.ini”> ] > <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/order"> <order> <cust_id>1</cust_id> <cust_name>&name;</cust_name> <creditcardnum>999999999999</creditcardnum> <creditcardexpiry>0609</creditcardexpiry> <item> <prod_id>1</prod_id> <quantity>2</quantity> </item> </order> </soap:Body> </soap:Envelope>
Listing 2: malicious SOAP message
As expected the response looks as follows:
Thank you [contents of c:\boot.ini on the remote server]. Your order has been placed.
The information has been successfully disclosed.
Attack mitigation / countermeasures
If you are sure that your web service framework implements the SOAP 1.2 standard correctly you are not vulnerable to any of these attacks. In case you are not sure, manually check prior to parsing whether or not an opening DTD Tag is existent. If that is the case just discard the message.
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
- OWASP Foundation. Testing for xml injection. http://www.owasp.org/index.php/Testing_for_XML_Injection_%28OWASP-DV-008%29, January 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.
- Gregory Steuck. Xxe (xml external entity) attack. http://www.securityfocus.com/archive/1/297714, October 2002. Security advisory #1, 2002,Accessed 01 July 2010.