What is XXE Attack?
XML external entity (XXE) attacks are targeted against applications that parse XML input. They exploit weakly configured XML parsers, which process XML code that references external entities. XXE attacks can result in port scanning within the internal network, server-side request forgery (SSRF), data exfiltration, use of an organization’s servers to perform denial of service (DoS), and more.
In this article, you will learn:
- How Do XML External Entity Attacks Work?
- What are the Types of XXE Attacks?
- How to Prevent XML External Entity Injections?
- XXE Protection with NeuraLegion
How Do XML External Entity Attacks Work?
Many websites accept XML files containing user data, or an XML-based file like PDF, and return an XML-based output to the user. A malicious user can try to inject code referencing an external XML entity, which includes data from sensitive files on the server. When the server reads the XML, it parses the external entity, merges it into the final document, and returns it to the user with the sensitive data inside.
To be vulnerable a web application or service must meet three criteria:
- Users can provide XML content which is parsed by the server—for example by uploading files or using a text editor that supports XML format.
- The XML parser enables definition and use of entities.
- When receiving an XML input from a user, the XML parser parses and interprets external references in entities.
What are the Types of XXE Attacks?
Exploiting XXE to Retrieve Files
An attacker may attempt to retrieve files from a server filesystem. This requires modifying the submitted XML as follows:
- Editing or introducing a DOCTYPE element. This element specifies an external entity that contains the file’s path.
- To utilize the specified external entity, the attacker edits the XML data value in the response received from the application.
Here is an example from OWASP illustrating this attack:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
Exploiting XXE to Perform SSRF Attacks
XXE attacks can be used to induce server-side applications to make unwanted HTTP requests to a URL selected by the attacker (known as server side request forgery). To do this, the attacker must:
- Create an external XML entity with the target URL
- Use the entity within a data value
- If the value selected is returned by the application as a response, the attacker has two-way interaction with the server
- If it is not returned, the attacker can still perform a blind SSRF attack
Here is an example of an entity that generates an HTTP request to an internal system:
<!DOCTYPE foo [ <!ENTITY example-entity SYSTEM "http://internal.company.com/"> ]>
Blind XXE Vulnerability
A blind XXE vulnerability means that the application does process external XML entities in an unsecure way, but does not return those entities in its responses. This means attackers will need to use advanced techniques to detect the vulnerability and exploit it.
Attackers can still exfiltrate data using blind XXE, for example by causing the server to connect to a URL controlled by the attacker.
Retrieving sensitive data via error messages
Attackers may alternatively submit invalid XML to a server, triggering an XML parsing error. This can be done in such a way that the error message will disclose the sensitive data sought by the attacker.
Typically, the attacker defines an XML parameter entity named file with the contents of a sensitive
file on the server, and another entity called
eval, dynamically declaring an entity called
error, defined as the content of the sensitive file.
When the server evaluates the XML, it attempts to load a nonexistent file entity, and upon failing, evaluates the error entity. It then displays an error message, which reveals the content of the sensitive file.
How to Prevent XML External Entity Injections?
Here are three common ways you can prevent XXE attacks.
Manually Disabling DTDs
To prevent XXE vulnerabilities, you should configure XML parsers in your applications to disallow custom XML document definitions (DTDs). There are almost no functional trade-offs, because most applications rarely require custom DTDs.
However, the problem is that each programming language or software component may use a different parser, each with its own way to disable DTDs. If your application or project has several parsers, you need to configure each one manually.
Different parsers have different function names and functions, so you should check the relevant documentation. Refer to the OWASP XXE cheat sheet for a list of common parsers and how to configure them to disallow DTDs.
Application Server Instrumentation
Third-party code within an application may include XML parsers. By manually configuring parsers, you increase the risk of missing a parser somewhere in your application code or endpoints.
To automate this process, you can insert checkpoints within specific parts of code in order to monitor runtime execution flow. This lets you automatically monitor for classes that are related to XML processing. You can also use it to validate external DTD activity.
You can also use instrumentation to defend against the most dangerous XXE exploits, which involve external code execution.
Instrumented security sensors in a server enable visibility over application architecture and data flow. Dynamic Application Security Testing (DAST) and Runtime Application Self Protection (RASP) products use the code instrumentation approach.
Hardening Against XML Entity Vulnerabilities
Here are a few more things you need to do to create additional layers of security against XXE in your application:
- Use a Web Application Firewall (WAF)—WAFs have built-in rules against XXE and can prevent obvious malicious input from reaching the application.
- Use Dynamic Application Security Testing (DAST)—developer-focused DAST solutions scan for XXE vulnerabilities early in the development process, and help you remediate them vulnerabilities before they make it into production.
- Limit permissions—users of the application should have minimal, if any, permission to access to modify the file system.
- Validate inputs—ensure obviously invalid inputs do not reach the XML parsing logic. It is difficult to validate XML before parsing it, but it can make an attack more difficult, unless the attacker uses complex regular expression patterns.
- Handle errors—errors related to XML should show a meaningful error message, but no information about internals such as stack traces. The more data you report when an error occurs, the better equipped an attacker will be to use XXE.
- Use authentication and encryption—all internal connections should be authenticated, and data should be encrypted, to prevent attackers from sending arbitrary HTTP requests to internal hosts (an SSRF attack).
- Limit outbound traffic—application servers should be limited in their ability to connect to external and internal networks. In many XXE attacks, attackers transmit files to remote servers, or scan ports on the internal network. Limiting outbound connections can prevent both of these.
- Limit DNS—DNS can also be used by attackers to exfiltrate data (as in DNS tunnelling). If you must use DNS on the server, configure upstream DNS servers to resolve only specific hostnames using a private zone.
XXE Protection with NeuraLegion NexDAST
NeuraLegion’s NexDAST helps automate the detection and remediation of many vulnerabilities including XXE, early in the development process, across web applications and APIs.
By shifting DAST scans left, and integrating them into the SDLC, developers and application security professionals can detect vulnerabilities early, and remediate them before they appear in production. NexDAST completes scans in minutes and achieves zero false positives, by automatically validating every vulnerability. This allows developers to adopt the solution and use it throughout the development lifecycle.
Scan any web app, or REST, SOAP and GraphQL APIs to prevent XXE vulnerabilities – try NeuraLegion NextDAST free