XML External Entities
Written by: anshul vyas
XML: Extensible Markup Language
As its name implies, XML stands for extensible markup language. A markup language consists of a set of codes, called tags, used to describe a text in a digital document. HTML is the most popular markup language for websites.
XML External Entity
A XML external entity is a type of custom XML entity with defined values that are loaded outside of the DTD in which they are declared. From a security perspective, external entities are particularly interesting because they allow an entity to be defined based on the contents of a file path or URL. XML External Entity attacks are attacks against applications that parse XML input.
When an XML parser with weakly configured XML processing options is used to process XML input containing an external entity reference, this attack can occur. XXE is only used to obtain files containing “valid” XML, not binary files.
XML Injection
An attacker can interfere with an application’s processing of XML data using XML external entity injection (or XXE for short) on the web.
Working
By storing and transporting data using a tree-like structure of tags and data, XML uses a tree-like structure. An XML document can be accompanied by a document type definition (DTD) that specifies the data values, permissions, and so on. There are two ways to use the DTD: it can be incorporated into the document itself or it can refer to an external version. Custom entities whose definitions are located outside the DTD where they are declared are referred to as XML external entities when the document refers to an external DTD.
XML Injection
It is possible for malicious parties to intercept or alter data passed between an application and its server via XML external entity injection (XXE). Malicious parties can also perform SSRF attacks or launch blind XXE attacks by retrieving files from your server.
It is possible to modify the structure of a resulting XML document by using XML metacharacters. XML injection vulnerabilities occur when the user inserts input into a server-side XML document or SOAP message in an unsafe way.
Types of XML Injection Attacks
It is possible to attack any application that parses XML input with the attacks described in this topic. In particular, the attacker creates malformed or crafty XML that is consumed by the application with the intent of tricking the XML parser into doing some damage. In general, two types of attacks can occur against XML parsers that have bugs or are misconfigured.
XML Bombs
A Denial-of-Service attack can occur when the XML parser crashes or does not process certain input data correctly.
XXE Disclosure
A parser may inadvertently disclose sensitive information. The following sections describe how each type of attack is instigated. Be aware that attacks can utilize either perfectly valid XML, or potentially malformed XML (unless the parser detects it and rejects it cleanly).
XML Bomb Attacks
There are many types of XML Bombs, but they are all designed so that they cause the XML parser, or the application that processes their output, to hang or crash when they execute. The Billion Laughs Attack, for example, uses a short XML file to grow into about 3 gigabytes of data during XML parsing. It is easy to see how the data size could be arbitrarily increased, and the large resultant data typically crashes any application.
Mitigating XML Bombs
An application can avoid XML bombs by configuring the XML parser to disable inline entity expansion. It is impossible for the attacker to increase the geometric size without inline expansion, which results in these attacks being rendered harmless. Set the parser to enforce a limit on the size of expanded entities when the application requires entity expansion, or if the XML parser does not provide this configuration option.
The following sample code disables inline DTDs in the standard .NET 4.0 XML parser:
XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit; XmlReader reader =
XmlReader.Create(stream, settings);In this configuration, neither of the XML Bombs would consume excessive amounts of memory. Instead of storing gigabytes of data, the data structure would display the entity expansion structure from the source XML. In order to avoid causing a Denial of Service, the application would have to construct the expanded form of the relevant entity directly and ensure that appropriate checks are made during the process.
XML External Entity (XXE) Attacks
External entities are one feature of general XML that can be used to attack applications. When an attacker provides an XML input containing a reference to an external entity, the XML parser will read that referenced data and process it into a resultant XML document. XML External Entities allow replacement values to be pulled from external URIs so that files and network resources can be accessed. It is possible for the attacker to exploit the XML parser process’ privileges to manipulate the resulting data, thereby exfiltrating the data. References to very large data sources may also lead to Denial of Service attacks.
As an example, let’s say an XML input references /dev/random, a pseudorandom bytes file that runs indefinitely (specifically, successive reading of random bytes will block when the system’s entropy pool is depleted, and will resupply data when it resupplies it again). An XML parser will read and construct data from an external entity until the end of the file. This will overload the system to the point of failure.
!ENTITY xxe SYSTEM file:///dev/random>Mitigating XML External Entity (XXE) Attacks
By preventing external references from being resolved entirely, XML parsers can prevent XXE attacks.
The configuration code in .NET 4.0 prevents attacks of this nature:
XmlReaderSettings settings = new XmlReaderSettings();
settings.XmlResolver = null; XmlReader reader =
XmlReader.Create(stream, settings);
PHP uses the default XML parser when processing XML:
libxml_disable_entity_loader(true);In some cases, XML external entities could be necessary or even indispensable, which would make completely disabling them not an acceptable solution. In these cases, you could consider configuring or modifying the XML parser to implement one or more of these strategies:
- Prevent attacks that delay or involve very high data volumes by enforcing a timeout.
- Data retrieval is limited to certain types and amounts.
- You can prevent the XmlResolver from retrieving resources from your local computer.
The use of local modifications poses an ongoing maintenance issue in keeping up with future versions of the base code. Additionally, modifying an XML parser will be complex and can introduce new security vulnerabilities.
In contrast, any XML parser without safe configuration may not have been developed with security concerns in mind and can be challenging to secure unless thoroughly reviewed and considerable effort is put into it. The best approach is to use XML parsers that can be configured to mitigate security threats.
It is also possible to protect against arbitrary files being treated as XML by requiring a valid header by checking that the XML data presented to the XML parser is valid. Because XML parsers may behave in an unknown way when a file is malformed, this can be useful.
Summary
It is possible for an application to cause harm when it parses specially crafted XML input. XML bombs (denial of service) and XXE (information disclosure or denial of service) are both well-known attacks. A preferred mitigation is to configure the XML parser in such a way that XML’s features that cause these problems are disabled or at least safely limited. There may be instances when configuration isn’t sufficient, and it may be necessary to modify the XML parser, but this is a riskier and more labor-intensive option.
