XML External Entities (XXE) can lead to XML injection vulnerabilities that can be used in different attacks such as remote request execution from a server, view files on the application server filesystem, unauthorized interaction with any back-end or external systems, data extraction, Denial of Service and server-side request forgery (SSRF), etc. Applications and XML­ based web services are especially vulnerable to such attack.

How do XXE vulnerabilities arise?

Mobile devices, browsers, and APIs all use an XML file standard for data sharing. As the use of XML picks up, so does the need to parse such large amounts of XML data. Unfortunately, the vulnerabilities in XML parsers have led to an increase in injection attacks.

Although XML External Entities and their functions are not malicious by themselves, XML parsers are frequently misconfigured to allow vulnerabilities. This is especially the case with older parsers.

XML External Entity enables attackers to disclose normally protected files from a server or connected network. XXE is a form of Server-Side Request Forgery that relies on the ability to write to a Document Type Definition (DTD). A DTD can be thought of as the building blocks of an XML file, since XML has no defined structure.

Since, the DTD defines the structure of the XML, when the XML file runs, it seeks out the DTD file to understand its own file format structure. If a hacker can manipulate that DTD file, they can create an XXE injection attack.

In this example, the DTD file creates a variable called “crce”, which references a file on the local webserver /etc/passwd. This is a common Unix password file that contains password hashes.

As the DTD is read, it then displays the file contents in <creds> and <user><pass> tags, which will act to display the contents of the file and reveal the hashed credentials in the passwd file.

XXE Attack Scenario during login

XXE is also a potential problem when authenticating into applications. Consider the XML request that is sent or received over HTTPS by the API of the mobile application.

From the mobile app, credentials for vijay_kumar are sent over as a username and password. The server responds that the credentials are valid and the app can complete the login process.

In contrast, let’s take a look at a malicious version of the login XML sent by the mobile application to the API. Notice that we are simply adding more document tags to the original XML request in anticipation of how the XML parser may interpret the data.

In the worst case, if the parser allows XXE, then the response provided by the API could contain what you see here, which is the /etc/passwd file that is used to keep track of registered users on a system. The attacker can retrieve this file and perform a successful XML Injection attack

Denial of service attack using XXE

XXE can also be tricked to do denial of service attacks. There is an example below:

Notice, the defined entities. The first one is simply a string that contains ” lol”. The next entity, called lol1, contains 10 references of the first entity. In practice, this would expand to the string “ lol ” 10 times in a row. The next entity, lo12, references lol1 10 times, and so on.

Now, we can see that the element user references the entity lol7, which expands into a string containing lol6 10 times, which expands into a string containing lol5 10 times, and so on. This results in a string of more than 1.2 GB large.

This is exponential expansion, and the amount of resources consumed by this attack cause a denial of service.

Probe internal network using XXE

XXE attacks also have the potential to probe internal networks. This works by using the HTTP protocol in an XXE attack. This way, XXE becomes an HTTP scanner that probes a victim’s internal network for web scanners. This sort of exploit is can be done using a simple script.

This isn’t limited to HTTP. Different XML parsers enable different protocols by default, so we could also probe for FTP servers, for example.

Countermeasures against XXE Vulnerabilities

We can defend against XXE by disabling external entities and DTD processing, implementing input validation controls, using JSON, and keeping XML processors patched. Let refer each of countermeasures in detail:

Disable XXE and DTD Processing

While XML parsers are often unsafe by default and don’t often consider security, you can avoid XXE injection by disabling DTDs. it’s as simple as that. Most libraries for parsing XML have external entities and DTD processing disabled by default.

However, it’s important to note that many XML parsers are not configured for security, so they often enable DTD processing.

For example, .NET’s XmlDocument parser allows DTDs by default and must be configured by the user.

In some cases, parsers have security features that address their vulnerabilities. For instance, XmlSecureResolver was introduced in the .NET framework to secure the XmlResolver parser. Without securing this class, attackers can retrieve sensitive documents or send their own XML.

Review the XML parsers you use, how they’ve been configured, and whether they have strong security features. If all else fails, disabling XXE and DTD processing entirely is the best way to avoid XML vulnerabilities.

Implement Input Validation Controls

You can reduce the impact of XXE by implementing a strict whitelist for server-side input validation. A whitelist defines all of the input considered acceptable, and rejects everything else. Use this along with filtering or sanitization to avoid hostile data within XML documents, headers, or nodes.

Additionally, you can verify that XML or XSL file upload functionality validates incoming XML. To do this, use XSD
validation, or a similar feature. XSD validation checks an XML file or string against an XML schema, or XSD. XSD schemas describe the structure of XML and make sure that XML can be parsed before checking it for errors and warnings.

Simply Use JSON

simple defense against XXE is just not using it. Instead, you can use less complex data formats like JSON. JSON is easier and faster to parse and helps you avoid the serialization of sensitive data that can happen with XML. However, depending on your use case, JSON may not have the versatility of XML.

Update and Patch

A good habit to have with any software is to patch and upgrade it regularly, so make sure the XML processors and libraries are up-to-date. This includes those in your application and the underlying operating system.

You can also use dependency checkers to scan your project dependencies for any publicly known vulnerabilities. These checkers are useful because it can be challenging to keep track of dependencies and their known vulnerabilities otherwise.

If your application uses SOAP prior to version 1.2, it’s likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework. Update SOAP to SOAP 1.2 or higher.

For an even more in-depth list of defenses against XXE and code samples, see the OWASP XXE Cheat Sheet.

Key Takeaway from this article

In summary, we saw that XML External Entities are not harmful by themselves, but attackers can exploit their poorly configured parsers and DTD files to reveal resources or files.

• Attackers can also exploit XXE to perform XXE injection, denial of service attacks, and probing attacks.
• We also saw that the best defense against XXE vulnerabilities is to disable XXE and DTD processing or to avoid XML altogether.
• We can also use strict input validation and keep your software updated to help defend against attacks.