XXE Injection: Manipulating XML Parsers

Hello! Welcome back to our module on advanced server-side vulnerabilities.

In our last lesson, you got hands-on experience exploiting insecure deserialization. You learned how an application that blindly trusts and parses structured data (a Python Pickle object) can be tricked into executing arbitrary code. Today, we're exploring a very similar theme but with a different data format: XML.

Our learning outcome is to identify XML External Entity (XXE) injection vulnerabilities by manipulating XML parsers. We'll cover how to spot and exploit these vulnerabilities, not just in obvious places, but also in hidden attack surfaces that are often missed by beginners. This is a critical skill for both penetration testing and bug bounty hunting.

We will cover:

1. The fundamentals of XML, entities, and how they become a vulnerability.
2. How to perform a classic XXE attack to read local files from a server.
3. Advanced techniques to find XXE in non-obvious places, like file uploads and by manipulating request headers.

1. Understanding the Root Cause: What is an XXE Vulnerability?

XML (eXtensible Markup Language) is a format for structuring, storing, and transporting data. A key feature of XML is the ability to define entities. Think of an entity as a variable or a macro. For example, you could define an entity &company_name; to represent "ACME Corp".

The vulnerability arises when an XML parser is configured to process external entities. An external entity is one whose value is loaded from an external source, like a file path or a URL. An attacker can supply malicious XML that defines an external entity pointing to a sensitive local file (e.g., /etc/passwd). When the application parses this XML, it reads the file and may embed its contents into the response, disclosing it to the attacker.

This is fundamentally a parser vulnerability, where the line between data and instructions becomes blurred. The parser is trusted to process data, but an attacker tricks it into executing an instruction (read this file).

Let's start with a foundational reading from PortSwigger, the creators of Burp Suite.

To see this concept explained visually, the following video provides a quick and effective summary.

2. The Classic Attack: Identifying and Exploiting Basic XXE

The most straightforward scenario for XXE is when an application is clearly communicating with the server using XML. You can spot this by looking for a Content-Type: application/xml or Content-Type: text/xml header in HTTP requests, or by simply seeing XML data in a request body.

The attack payload has two parts:

1. Define the entity: You add a <!DOCTYPE> element to define your malicious external entity. This points the parser to the resource you want to access.

   <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
   

2. Reference the entity: You use the entity you just defined somewhere in the XML data. The & and ; are used to reference it.

   <productId>&xxe;</productId>
   

When the parser processes the <productId>, it replaces &xxe; with the content of the /etc/passwd file. If the application reflects the product ID in its response, you'll see the file's contents.

Let's turn to a practical demonstration of this attack using Burp Suite.

The PortSwigger article you read earlier also provides a clear, text-based example of this exact attack. You can refer to the section "Exploiting XXE to retrieve files" in resource LINK for a static payload example.

<?xml version="1.0" encoding="UTF-8"?>
<profile>
    <name>testuser</name>
    <email>test@example.com</email>
</profile>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE profile [ <!ENTITY xxe SYSTEM "file:///etc/hostname"> ]>
<profile>
    <name>testuser</name>
    <email>&xxe;</email>
</profile>

3. Finding Hidden Attack Surfaces for XXE

Relying on seeing Content-Type: application/xml will cause you to miss most XXE vulnerabilities. Expert testers know how to find "hidden" attack surfaces. Let's explore two of the most common ones.

Scenario A: XXE via File Uploads

Many modern applications allow users to upload files like avatars, documents, or data sheets. Some of these file formats are actually XML-based. A prime example is the SVG (Scalable Vector Graphics) image format. Others include office formats like DOCX and XLSX.

If an application allows you to upload an SVG file and processes it on the server (e.g., to resize or validate it), you can embed an XXE payload directly into the SVG file's XML structure.

The next segment of The Cyber Mentor's video demonstrates this perfectly.

Scenario B: XXE via Content-Type Modification

Sometimes, an application endpoint is designed to handle multiple content types, even if it defaults to something like JSON or standard form data. A common example is a web API that can respond to both application/json and application/xml for broader compatibility.

You can test for this by taking a normal POST request (e.g., with a JSON body) and trying to:

1. Change the Content-Type header to application/xml.
2. Reformat the request body from JSON to the equivalent XML structure.
3. Inject your XXE payload into the new XML body.

If the server's framework is configured to automatically parse XML when it sees the corresponding content type, your payload will be processed.

A final technique worth knowing is the XInclude attack. If you find you can inject content into a server-side XML document but cannot control the DOCTYPE, you may be able to use <xi:include> to include external files. This is another way to force the parser to read local files. The PortSwigger article (LINK, section 3) also provides a good example of this.

Conclusion

In this lesson, you learned how to identify and test for XML External Entity injection, a serious vulnerability stemming from insecure XML parsers.

Key Takeaways:

• Core Vulnerability: XXE occurs when an XML parser processes an external entity defined by an attacker, allowing them to read local files or interact with other systems.
• Classic Payload: The attack requires defining a DOCTYPE with a malicious SYSTEM entity and referencing it within the XML body.
• Hidden Attack Surfaces: You must look beyond obvious XML requests. Key hidden vectors include:
  • File Uploads: Exploiting XML-based file formats like SVG or DOCX.
  • Content-Type Switching: Forcing an endpoint to parse XML by modifying the Content-Type header.
• Manual Testing is Key: While scanners can find basic XXE, identifying hidden vulnerabilities often requires the manual, creative techniques you learned today.

Next Lesson Preview:

So far, we've used XXE to read files whose contents are returned directly in the application's response. But what if they aren't? And what else can we do besides reading files? In our next lesson, we will explore Server-Side Request Forgery (SSRF). You will learn how to identify and exploit SSRF, and we will revisit XXE as a powerful technique to trigger SSRF attacks, enabling you to scan internal networks and interact with sensitive internal services.