The OWASP Top 10 is an awareness document that focuses on the 10 most critical risks for Web Application Security. The document is freely available, and OWASP recommends that organizations adopt the outlined best practices into their application workflows for improved web application security.  Out of the list of security risks, XML External Entity (XXE) vulnerability is one such OWASP security risk that focuses on parsed XML input using misconfigured processors. 

This article delves into how XXE attacks are carried out, risks associated with such attacks, and various best practices and tools to mitigate such risks.

Table of contents
  1. XXE Security Assessment Level
  2. What are XXE Attacks?
  3. What are XML External Entities?
  4. What Are the Risk Factors for XXE Attacks
  5. Type of XXE Attacks
  6. How to Detect and Identify XXE Attack Surfaces
  7. Best Practices to Prevent XXE Vulnerabilities
  8. Popular Tools to Prevent XXE Attacks
  9. How to Fix XML External Entity (XXE) Processing Vulnerabilities?
  10. Summary

XXE Security Assessment Level

Security Assessment New XXE-2-2-4

CVSS Vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L/CR:H/IR:H/AR:H/MAV:N/ MAC:L/MPR:N/MUI:N/MS:U/MC:H/MI:H/MA:H

What are XXE Attacks?

Some web applications include XML processors that evaluate untrusted external references within an XML file. These references enable attackers to use external parameter entities to disclose various configuration file information, which the attackers then use to exploit the system further. 

Since these attacks occur through parsing XML inputs in an application, attackers can leverage it to access other integrated systems, leading to application unavailability and loss of sensitive data. It is, therefore, prudent to understand the nature of these attacks and how they can be prevented.

What are XML External Entities?

External entity profiles are defined by outside sources such as a file on a local computer or a web URL. Such entities are used to ensure that the XML processor behaves consistently even when unexpected characters are parsed. 

External entities have various legitimate use-cases:

  • Calling an XML document hosted locally to be used in another XML document
  • Dividing documents into smaller, logical units
  • Referring to the same entity framework multiple times without having to repeat the same element
  • Using external entity references with different encoding in the same document

If the parser that processes external entities is weakly configured, hackers can intercept data going to the server and inject malicious payloads. Attackers typically also exploit custom external entities to access sensitive data.

Check Your Web App or APIs for XXE Attacks

SCAN FOR FREE NOW

What Are the Risk Factors for XXE Attacks

An application is considered susceptible to XXE attacks typically on account of the following scenarios:

Web application parses XML Documents

If an application accepts XML documents via uploads or directly as an input, attackers can manipulate the XML document, allowing them access to system files and configuration information.

Tainted Data within the Document Type Declaration (DTD) Identifier

If DTD processing is enabled within the XML parser, attackers can orchestrate the billion laughs attack — a type of Denial-of-Service attack that is based on using recursive entities.

XML Processor Validates and Processes DTD

If DTD validation is enabled for XML processing, attackers can use XML documents to access local resources and stop them from returning data. Additionally, if the XML Parser resolves external entities within the DTD, attackers can expose the contents of sensitive files by making requests using a malicious system identifier URL.

Type of XXE Attacks

Attackers tend to target External XML Entities since an XML parser is logically not built to check external content. The resolved external content can contain anything, including malicious payloads, making XXE attacks inherently dangerous. 

XXE attacks are orchestrated using a variety of mechanisms, including:

XXE for File Retrieval

To access sensitive file contents, an attacker can craft a malicious request using the system identifier URL. If the XML parser processes external entities, the server may expose the contents of a file system in its response. This way, the attacker can access credential files, system files, source code, and sometimes even directory listings of all integrations in the absence of robust security mechanisms.

XXE for Server-Side Request Forgery (SSRF)

Attackers can use XXE payloads to gain indirect access to internal networks and launch attacks using requests originating from a legitimate server. Following the execution of XXE on one web server, the attacker can send HTTP requests to other internal subsystems, thereby orchestrating a deeper full-blown attack.

Data out-of-band exfiltration

Out-of-band (Blind XXE) attacks don’t rely on an immediate response from the server. In this case, an attacker forces the XML processor to send additional controlled requests to the server. The server is then exploited to read the contents of the file intercepted during the attack.

Data Retrieval via Error Messages

Attackers can trigger an XML parsing error whose message contains the sensitive information they are looking for. This approach only works if the server returns the complete error message within its response.

How to Detect and Identify XXE Attack Surfaces

Most attack surfaces for External Entity Injection (XXE Injection) attacks are obvious. This is because the web server’s HTTP traffic includes requests with XML data. To detect attack surfaces that don’t contain XML, organizations can identify External Entity Injection attack surfaces in a number of ways:

XXE Attacks via file upload

Some applications allow clients to upload files, which are processed and validated by the webserver. If the file processing library supports XML subcomponents, the attacker can submit malicious documents to reach the attack surface.

Modified Content-Type

Some web servers tolerate specific XML content types. If the application can receive requests with XML in the message body, attackers can expose the attack surface by reformatting POST requests to use XML.

XInclude Attacks

When a client submits data, some applications embed the data to an XML document, which is then parsed. In this case, rather than controlling the entire XML document, attackers can use XInclude, which specifies the subcomponents used to build XML documents. These subcomponents can be included within any data value in the XML document by referencing the XInclude namespace and a path to the file they wish to include.

Blind XXE Vulnerabilities

Attackers tend to define external entities using a URL to an application they target to control. Such vulnerabilities can be identified by monitoring traffic of various application interactions.

Best Practices to Prevent XXE Vulnerabilities

While it is never sufficient to disable the resolution of external entities, there are plenty of methods to effectively prevent XXE attacks. This section explores the tools and practices that organizations can leverage to prevent attacks through External XML Entities.

Use simple data formats

Organizations should use a secure default configuration that allows simple data formats, such as JSON, that can be easily validated before being processed by the XML parser. 

Use updated XML processes and libraries

Older XML processors and libraries rely on outdated document type definitions, which weaken the XML parser. Security teams should, therefore, update their XML libraries and processors to avoid serialization and exposure of sensitive data.

Disable Document Type Definition and XXE in all XML Parsers

Disabling DTD functionality or external entity support ensures that no attacker can inject malicious payloads into the data transport protocol.

Use Whitelisting for Server-Side Input Validation

Whitelisting protects applications and networks from remote code execution by unauthorized entities and untrusted sources. This ensures that legitimate workloads and requests can be processed with the XML parser.

Utilize SAST Tools to Identify XXE Attack Surfaces in Source Code

While manual code review can help teams identify potential attack surfaces, SAST tools automate the detection of vulnerabilities in source code and are considered one of the most effective ways to eliminate XXE vulnerabilities within a source code.

Some of the popular security products that can help organizations identify and eliminate XXE attack surfaces include:

Crashtest Security Suite

Crashtest Security is a comprehensive vulnerability scanning tool that enables security teams to establish a continuous testing process to reduce security vulnerabilities. With Crashtest Security, teams can develop and deploy safer web applications by testing them and using OWASP recommendations as benchmarks.

The platform’s end-to-end vulnerability scanner helps eliminate XXE attack surfaces and security blindspots since it scans almost every web technology, including — APIs, AJAX, HTML5, Javascript, Multi-page applications, and single-page applications.

Portswigger Burp Suite

The Burp Suite vulnerability scanner leverages Portswigger’s research to help teams detect a wide range of web vulnerabilities. The scanner uses a crawl engine to find vulnerabilities even in heavy applications where other scanners may stop at obstacles such as volatile URLs, stateful functionality, and CSRF tokens.

Hdiv

A complete vulnerability management solution that uses a data flow control system to help teams eliminate XXE attack surfaces by their applications. The information flow control mechanism prevents breaking the original server contract, allowing teams to identify exactly which subcomponent can be accessed by each user.

Acunetix

A vulnerability management platform that offers inbuilt vulnerability assessment and scanning. The solution integrates with market-leading DevOps tools to increase security stance and eliminate most security risks at low costs.

Netsparker

An automated, quick vulnerability scanner that detects vulnerabilities along with suggesting mitigation techniques. The platform also supports multiple integrations and third-party security solutions for a comprehensive vulnerability assessment.

How to Fix XML External Entity (XXE) Processing Vulnerabilities?

An XXE vulnerability exists when a web application parses XML documents from an untrusted source. If the underlying XML parser accepts DTD, an attacker can manipulate the XML document to allow him to read files on the system. For example, the following code snippet shows a malicious XML document that forces the application to read sensitive files on the server.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE credentials [
<!ELEMENT credentials ANY >
<!ELEMENT user ANY >
<!ENTITY user SYSTEM "file:///etc/passwd">]>
<credentials>
    <user>&user;</user>
    <pass>mypass</pass>
</credentials>

A poorly configured XML parser would read the file specified in the DTD and possibly display it to the attacker. Therefore, to protect your web application from this kind of attack, you can disable the entity loader for the XML parser, as the below snippet shows.

libxml_disable_entity_loader(true);

Additionally, to disabling the entity loader, it is recommended to use a local static DTD and remove any other DTD included in the XML document.

Summary

Since a successful attack leads to request forgery, denial of service, and disclosure of sensitive data, XXE attacks are considered one of the top security risks as per OWASP and the Common Weakness Enumeration (CWE) database. XXE attacks are particularly prevalent because it can be carried out by a number of attack vectors and is still considered a novel attack mechanism due to the lack of understanding among security teams.  

By helping teams identify attack surfaces before hackers exploit them, Crashtest Security reduces the risk of being exploited through XXE attacks. The platform’s scanner outputs accurate reports and remediation advice that enables organizations to stay ahead of malicious actors. 

Try Crashtest Security today to discover how it integrates into your development stack for efficient, automated vulnerability scanning.

See if Your Web App or API Has Security Vulnerabilities

SCAN FOR FREE NOW