The OWASP Top 10 is an awareness document focusing 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, the risks associated with such attacks, and various best practices and tools to mitigate such risks.
XXE Security Assessment Level
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 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.
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 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 Denial-of-Service attack based on 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 dangerous.
XXE attacks are orchestrated using a variety of mechanisms, including:
XXE for File Retrieval
An attacker can craft a malicious request using the system identifier URL to access sensitive file contents. 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 without 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 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 several ways:
XXE Attacks via file upload
Some applications allow clients to upload files, which are processed and validated by the webserver. The attacker can submit malicious documents to reach the attack surface if the file processing library supports XML subcomponents.
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.
Try our automated XXE vulnerability scanner
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, to 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. They are considered one of the most effective ways to eliminate XXE vulnerabilities within a source code.
Popular Tools to Prevent XXE Attacks
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 and eliminate most security risks at low costs.
Invicti
An automated, quick vulnerability scanner detects vulnerabilities and suggests 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);To disable the entity loader, it is recommended to use a local static DTD and remove any other DTD included in the XML document.
Video: What is XXE and how to prevent it?
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 they can be carried out by several attack vectors and are 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, enabling 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.
