XXE Injection: Exploiting XML Parsers to Breach Internal Networks

To comprehend XXE, one must first understand the concept of XML Entities. In the XML specification, an entity is essentially a variable—a shortcut that allows developers to define a chunk of data once and reference it multiple times throughout the XML document.

Entities are defined within the Document Type Definition (DTD) section at the beginning of an XML payload.

• Internal Entities: These are standard variables where the value is defined directly within the DTD. (e.g., <!ENTITY author "Rokibul Islam">)
• External Entities: This is where the vulnerability lies. The XML specification allows an entity to pull its value from an external source, typically defined by a Uniform Resource Identifier (URI) or a local file path. (e.g., <!ENTITY external SYSTEM "http://example.com/data.txt">)

When a weakly configured XML parser processes a document containing an external entity, it obediently fetches the data from the specified external URI or file path and substitutes it into the XML document before passing the data to the application logic.

The core vulnerability exists because many popular XML parsing libraries (across Java, PHP, .NET, and Python) have support for external entities enabled by default. If an application accepts XML input from a user and parses it without explicitly disabling this feature, it is vulnerable to XXE.

1. Reading Sensitive Local Files

The most common and immediate objective of an XXE attack is local file disclosure. An attacker can define an external entity using the file:// protocol to point to a sensitive configuration file on the server.

Consider a vulnerable e-commerce application that accepts XML to process inventory checks:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck>
    <productId>&xxe;</productId>
</stockCheck>

When the vulnerable server parses this XML, it encounters the &xxe; entity. It follows the instruction to load the contents of the /etc/passwd file (a highly sensitive Linux system file) and substitutes it into the <productId> node. If the application then returns the "productId" in its HTTP response (e.g., "Invalid product ID: root:x:0:0..."), the attacker has successfully stolen the contents of the file. Attackers will use this to target SSH keys, database configuration files containing passwords, and source code.

2. Server-Side Request Forgery (SSRF) via XXE

If reading local files isn't enough, XXE can be weaponized to turn the compromised web server into a proxy for the attacker, executing a Server-Side Request Forgery (SSRF) attack.

Instead of using the file:// protocol, the attacker uses the http:// protocol to force the web server to make requests to the internal network. The web server (which is trusted by internal firewalls) is coerced into attacking systems that the attacker cannot reach directly from the internet.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY ssrf SYSTEM "http://192.168.1.50/admin-panel"> ]>
<stockCheck>
    <productId>&ssrf;</productId>
</stockCheck>

Using this technique, an attacker can systematically map the internal network (by checking which IP addresses respond) and access internal administrative interfaces, cloud metadata endpoints (like the AWS 169.254.169.254 endpoint to steal IAM credentials), and unauthenticated internal databases.

3. Blind XXE and Out-of-Band (OOB) Exfiltration

In many scenarios, the application is vulnerable to XXE (it parses the external entity), but it does not return the value of the entity in the HTTP response. This is known as Blind XXE. The attacker cannot simply read /etc/passwd in the browser.

To overcome this, attackers utilize Out-of-Band (OOB) exfiltration. They craft a complex, multi-stage DTD payload.

1. The attacker forces the vulnerable server to load a malicious DTD file hosted on a server controlled by the attacker.
2. This malicious DTD instructs the vulnerable server to read the target file (e.g., C:\Windows\win.ini).
3. The DTD then instructs the server to append the contents of that file to a URL query string and make an HTTP or DNS request back to the attacker's server (e.g., http://evil.com/?data=[contents_of_win.ini]).

The attacker then simply checks the logs on their own web server to retrieve the stolen file contents, completely bypassing the fact that the vulnerable application did not return the data in its response.

Example 1: The Cloud Metadata Theft An attacker discovers an XXE vulnerability in a web application hosted on Amazon Web Services (AWS). The application accepts SVG image uploads (SVG is an XML-based image format). The attacker uploads a crafted SVG file containing an XXE payload that targets the AWS EC2 Instance Metadata Service (IMDS).

<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role">

The vulnerable XML parser processes the SVG, reaches out to the IMDS endpoint, retrieves the temporary, highly privileged IAM access keys for the "admin-role", and embeds them in the image metadata. The attacker downloads the processed image, extracts the keys, and gains total administrative control over the victim's AWS cloud environment.

Example 2: Breaching the Internal Network A Penetration Tester is tasked with evaluating a corporate HR portal. The portal uses SOAP (XML) for communication. The tester discovers a Blind XXE vulnerability. By crafting an Out-of-Band payload, the tester forces the HR server to systematically send HTTP requests to internal IP addresses (10.0.0.1 through 10.0.0.255). The tester monitors their malicious server to see which internal IPs the HR server successfully connects to. Through this SSRF scanning, the tester discovers an unauthenticated internal Jenkins server. The tester then uses the XXE vulnerability to forge requests to the Jenkins API, eventually achieving Remote Code Execution (RCE) on the internal CI/CD pipeline.

Unlike many vulnerabilities that require complex code refactoring, mitigating XXE Injection is typically straightforward, provided developers understand how their chosen XML parsing library functions.

1. Disable External Entities: The most effective and reliable defense against XXE is to explicitly disable the processing of external entities and DTDs entirely within the XML parser configuration. How this is done varies by language and library:
   • Java (DocumentBuilderFactory): dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
   • Python (lxml): Utilize the defusedxml library, which is designed specifically to prevent XML attacks by disabling entity resolution by default.
   • C# / .NET: Modern versions of .NET (4.6 and above) have XML resolvers disabled by default. For older versions, set XmlReaderSettings.XmlResolver = null;.
2. Use Safer Data Formats: Wherever possible, modern applications should avoid using XML for transmitting complex data structures. Transitioning to JSON (JavaScript Object Notation) eliminates the risk of XXE entirely, as JSON does not support entities or DTDs.
3. Implement Server-Side Request Forgery (SSRF) Protections: Because XXE is frequently used to execute SSRF attacks, organizations must implement defense-in-depth on the network level. Web servers should be placed in heavily restricted DMZs with egress firewall rules preventing them from making arbitrary outbound HTTP requests to the internet or to sensitive internal network segments.
4. Virtual Patching and WAFs: While not a permanent solution, deploying a Web Application Firewall (WAF) can help identify and block common XXE payloads (e.g., blocking requests containing <!DOCTYPE or SYSTEM "file://"), providing temporary protection while the underlying code is patched.
5. Source Code Auditing: Development teams should utilize Static Application Security Testing (SAST) tools to automatically scan their codebases for instances where XML parsers are instantiated without explicit security configurations disabling external entities.