XXE (XML External Entity)

What Is XXE (XML External Entity)?

XML external entity injection (XXE) is a security vulnerability that allows a threat actor to inject unsafe XML entities into a web application that processes XML data. Threat actors that successfully exploit XXE vulnerabilities can interact with systems the application can access, view files on the server, and in some cases, perform remote code execution (RCE).

XXE vulnerabilities are caused by XML parsers that are outdated or not properly configured. In theory, it is easy to prevent by setting XML parser configuration to disallow custom document type definitions (DTD).

However, in practice, web applications can contain a large number of components, each of which might include an XML parser. It is difficult to ascertain which parts of the application process XML, and in some cases, application owners have no access to the configuration of the XML parser used by specific components.

What Is the Impact of XXE Attacks?

Here are common consequences of XXE attacks:

• Disclosing local files—threat actors can disclose files containing sensitive data, like passwords, using file: schemes or relative paths in the system identifier.
• Expanding the attack—XXE attacks rely on the application that processes the XML document. Threat actors can use this trusted application to move to different internal systems.
• Remote code execution—if the XML processor library is vulnerable to client-side memory corruption, a threat actor can dereference a malicious URI to allow arbitrary code execution under the application account.
• Impacting application availability—some XML attacks might allow actors to access local resources that do not stop returning data. If too many processes or threads are not released, it can negatively impact application availability.

XXE Attack Example

XML files might contain document type definitions (DTDs) that allow defining and consuming XML entities. It is possible to define external entities using URIs. The XML parser will process this URI and add the resulting content into an XML document.

For example, an attacker can make the following request using a URI that points to a sensitive file on the server. If the XML parser is configured to process external entities, the web server will return the contents of that file.

Request

Response

What Are the Types of XXE Payloads?

There are several types of XML external entity attacks:

XXE Exploit to Retrieve Files

An XXE attack can retrieve an arbitrary file from the target server’s filesystem by modifying the submitted XML. The attacker introduces a DOCTYPE element defining an external entity that contains a path to the file. The attacker then edits the XML data value in the response.

XXE Exploit to Perform SSRF

Attackers can use an XXE attack to perform server-side request forgery (SSRF), inducing the application to make requests to malicious URLs. This attack involves defining an external entity with the target URL and using the entity in the response’s data value. It allows the attacker to view responses from the URL in an application’s response, enabling interaction with the back end. In some cases, the attacker can only perform a blind SSRG attack and cause damage without viewing the response.

Blind XXE Exploit to Exfiltrate Data

XXE vulnerabilities are often blind, meaning that the application doesn’t return any values of external entities. Attackers cannot directly retrieve server-side files but can still detect and exploit blind XXE vulnerabilities with advanced methods like out-of-band data exfiltration or triggering an XML parsing error to disclose sensitive information.

Blind XXE Exploit to Generate Error Messages

One way to exploit blind XXE vulnerabilities is to trigger parsing errors to generate an error message containing sensitive data. This approach is effective for applications that return a resulting error message in their response. Attackers can perform a blind XXE exploit by using malicious external DTDs to trigger an error message revealing the password file’s contents.

A malicious DTD can define a “file” XML parameter entity containing the password file contents. It also defines an evaluation entity with a dynamic declaration of an “error” entity, enabling an evaluation using a decoy file. The evaluation entity triggers the declaration of the “error” entity. It attempts to load a nonexistent file to evaluate its value, resulting in an error message revealing the nonexistent decoy file’s name.

XXE Prevention Best Practices

Here are popular XXE injections prevention techniques:

Manual XXE Prevention

You can prevent vulnerabilities in entities outside of XML by configuring the XML parser to disallow custom DTDs. Since applications rarely require DTD, there are very few functional trade-offs. However, every parser in each programming language comes with its own requirements for setting this parameter. As a result, a project containing several analyses might require manually configuring each solver correctly.

Here is how you can define features using an Apache XML project:

Note that different parsers come with different function names and characteristics. Check the documentation or the OWASP XXE cheat sheet when setting this configuration.

Disabling DTD Support

External DTDs are meant for use by trustworthy parties, but threat actors often exploit this legacy feature to attack web applications. You can disable DTD to prevent XXE attacks. However, if you cannot disable DTDs, you can still mitigate this risk by disabling the external entity functionality.

Application Server Instrumentation

Application server instrumentation technology injects checkpoints into specific code components to monitor the flow of executions at runtime. It works like a detective security sensor inside the server, offering real-time visibility into application schema and data for each request.

You can implement application server instrumentation using runtime application self protection (RASP) to add personalized protection for applications and interactive application security testing (IAST) to find vulnerabilities during execution.

Since the XML parser can be part of the application’s third-party code, you might miss some application parsers and endpoints, and manual configuration can be risky. Instrumentation helps eliminate the manual validation process by automating XXE prevention.

Instrumentation technology can automatically monitor key classes involved in XML processing and identify external DTDs activity. It can prevent external code execution, limiting the execution time of specific requests to minimize DoS attacks. It can also look for critical vulnerabilities.

XXE Protection with Imperva

Imperva provides two security products that are capable of blocking and mitigating XXE attacks:

• Web Application Firewall (WAF) prevents attacks with world-class analysis of web traffic to your applications. Malicious payloads from XXE attacks will primarily be blocked based on a negative security model (e.g. payload signatures). With WAF Gateway, the payloads can also be blocked when applying a positive security model (e.g. profiling).
• Runtime Application Self-Protection (RASP) offers real-time attack detection and prevention from your application runtime environment. With RASP, the execution of malicious payloads will be blocked, whether through the network security module or through the OS-command module.

Imperva also provides comprehensive digital security for applications, APIs, and microservices:

API Security—Automated API protection ensures your API endpoints are protected as they are published, shielding your applications from exploitation.

Advanced Bot Protection—Prevent business logic attacks from all access points—websites, mobile apps and APIs. Gain seamless visibility and control over bot traffic to stop online fraud through account takeover or competitive price scraping.

DDoS Protection—Block attack traffic at the edge to ensure business continuity with guaranteed uptime and no performance impact. Secure your on premises or cloud-based assets – whether you’re hosted in AWS, Microsoft Azure, or Google Public Cloud.

Attack Analytics—Ensures complete visibility with machine learning and domain expertise across the application security stack to reveal patterns in the noise and detect application attacks, enabling you to isolate and prevent attack campaigns.

Client-Side Protection—Gain visibility and control over third-party JavaScript code to reduce the risk of supply chain fraud, prevent data breaches, and client-side attacks.