OWASP Top Ten - XML External Entities (XXE)

Welcome to Secumantra! We have already covered top three vulnerabilities – injection, broken a uthentication and sensitive data exposure from OWASP Top Ten. In this post, we’re going to talk about the number four vulnerability in the OWASP Top Ten 2017 version – XML External Entities (XXE).

OWASP (Open Web Application Security Project) is a nonprofit foundation that works to improve the security of software. OWASP Foundation is globally recognized by developers as the first step towards more secure coding. It releases OWASP Top Ten List every 2-3 years sharing the most critical security risks to modern web applications. For more details, please read our previous post here.

What is XML External Entities (XXE)?

Extensible Markup Language (XML) is a very popular data format and is widely used by many types of web applications and services to exchange data among each other. In order to interpret and process XML data, a XML parser (or processor) is required and is extensively used in many applications. There are some well known open source libraries as well like xerces, libxml etc.

When the XML document is parsed, the XML parser will follow the link and read the linked document. Assuming the attacker can see the output of the parsed XML document, this gives them the ability to read local files on the server.

An XML External Entities (XEE) attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity (with malicious code) is processed by a weakly configured XML parser.

Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:

The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.
Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled.
If the application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.
If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.

Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack. These can have serious consequences and major security risks.

Example Attack Scenarios

XML has a few types of entities: an XML Schema Definition (XSD) or a Document Type Definition (DTD). These are also known as external entities, which can access local or remote content via a declared system identifier. From the two, Document Type Definition is the most susceptible to XXE vulnerabilities.

Numerous public XXE issues have been discovered, including attacking embedded devices. XXE occurs in a lot of unexpected places, including deeply nested dependencies.

The easiest way is to upload a malicious XML file, if accepted:
Scenario #1: The attacker attempts to extract data from the server:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
Scenario #2: An attacker probes the server’s private network by changing the above ENTITY line to:
<!ENTITY xxe SYSTEM "https://192.168.1.1/private" >]>
Scenario #3: An attacker attempts a denial-of-service attack by including a potentially endless file:
<!ENTITY xxe SYSTEM "file:///dev/random" >]>

Consequences

These vulnerabilities could lead to following consequences if not addressed properly:

Disclosure of confidential data – The most common XXE use case is to read local files on the server. This file is then either shown to the attacker directly on the website or sent to a server controlled by them.
Denial of service (DoS) – Using recursive linking can also lead to DoS, the most common way to do this is called the Billion Laughs Attack. In short, it is possible to force the XML parser to consume all the server’s resources until it crashes.
Server side request forgery (SSRF) – As it is possible to not only link local resources but also those hosted online, XXE can lead to SSRF, i.e. forcing the parser to make network requests within the local network. Security within the local network is often much weaker, leading to the possibility of further escalation for the attacker.
Port scanning from the perspective of the machine where the parser is located, and other system impacts.

Prevention

The easiest and most effective method is, to disable all the XML features (like DTDs) that the application does not need to use. This can be done through configuration options or by overriding default behavior within the code.

Example – if you are using Xerces XML parser, while using XercesDOMParser do this to prevent XXE:

XercesDOMParser *parser = new XercesDOMParser;
parser->setCreateEntityReferenceNodes(true);
parser->setDisableDefaultEntityResolution(true);

Additionally, developer training is essential to identify and mitigate XXE. Here is the list of some of the preventive measures against XXE:

Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data.
Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher.
Disable XML external entity and DTD processing in all XML parsers in the application. Refer OWASP Cheat Sheet ‘XXE Prevention’ for more details.
Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations.

If these controls are not possible, consider using virtual patching, API security gateways, Web Application Firewalls (WAF), or Interactive Application Security Testing (IAST) tools to detect, monitor, and block XXE attacks.

OWASP Risk Rating

Let us look at the OWASP risk rating matrix –

XML is widely used. OWASP rates the prevalence of XXE vulnerabilities as medium. It is not the most common OWASP category, but the severance is high which still places it high up on the Top 10 list.

XXE is easy to exploit. All the attacker needs is the ability to upload XML documents that are then parsed. Exploiting the vulnerability does not require much skill beyond this.

Summary

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities with malicious code can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

XXE vulnerabilities have been featured in the OWASP Top 10 list in 2017 for the first time and immediately made it to the number 4 spot. They can have serious consequences and should be treated as major security risks.

It is better to avoid such complex type of input and use something simpler like JSON. Also Static application security testing (SAST) and web vulnerability scanners can be used to discover such issues.

When securing your applications against this type of vulnerability, it is always a good practice to follow defense in depth strategy. Thank you for reading. Stay Safe, Stay Secure!