XML External Entity Injection (XXE) is a critical web security vulnerability that can expose applications to various risks. In this comprehensive guide, we will delve into the intricacies of XXE attacks, including what they are, how they arise, different types of XXE attacks, and effective prevention strategies. By the end of this article, you will have a solid understanding of XXE vulnerabilities and be equipped with the knowledge to protect your applications.
What is XML External Entity Injection (XXE)?
XML External Entity Injection, commonly referred to as XXE, is a vulnerability that allows attackers to manipulate the processing of XML data by exploiting custom XML entities. These entities, defined in the XML specification, can load values from external sources such as files or URLs. By injecting malicious entities, attackers can interfere with the application’s XML processing, potentially gaining unauthorized access to sensitive information, executing remote requests, or even compromising the underlying server infrastructure.
How do XXE Vulnerabilities Arise?
XXE vulnerabilities typically arise when applications use XML to transmit data between the browser and the server. Applications rely on standard parsing libraries or platform APIs to process XML data. These libraries often support potentially dangerous XML features, even if the application does not utilize them. External entities, a type of custom XML entity, pose a significant security risk as they can be defined based on the contents of a file path or URL. Attackers exploit this feature to craft malicious payloads that exploit XXE vulnerabilities.
Types of XXE Attacks
There are several types of XXE attacks that attackers can employ to exploit vulnerable applications:
1. Exploiting XXE to Retrieve Files
In this type of XXE attack, an external entity is defined to contain the contents of a file, which is then returned in the application’s response. By manipulating the submitted XML, attackers can introduce or edit a DOCTYPE element to define the external entity. They can then modify a data value in the XML to utilize the defined entity and retrieve arbitrary files from the server’s filesystem. This attack can enable attackers to access sensitive files, such as configuration files or user credentials.
2. Exploiting XXE to Perform SSRF Attacks
XXE vulnerabilities can also be leveraged to perform Server-Side Request Forgery (SSRF) attacks. Attackers define an external entity based on a URL to a back-end system and utilize the entity within a data value. If the defined entity is returned in the application’s response, the attacker gains the ability to view the response from the specified URL, effectively interacting with the back-end system. This can lead to unauthorized access, data leakage, or further exploitation of internal resources.
3. Exploiting Blind XXE to Exfiltrate Data
Blind XXE vulnerabilities occur when an application does not return the values of defined external entities in its responses, making direct retrieval of server-side files impossible. However, attackers can still detect and exploit blind XXE vulnerabilities using advanced techniques. Out-of-band techniques, such as monitoring interactions with a system controlled by the attacker or triggering XML parsing errors to reveal sensitive data in error messages, can be employed to exfiltrate data.
4. Exploiting Blind XXE to Retrieve Data via Error Messages
In some cases, attackers can exploit blind XXE vulnerabilities to retrieve sensitive data through error messages. By crafting malicious payloads that trigger parsing errors, the attacker can extract valuable information embedded within error messages. This technique can be particularly effective when applications provide detailed error messages containing sensitive data, such as database connection strings or user credentials.
To systematically test for XXE vulnerabilities, each data node in the XML should be tested individually to determine if the defined entity appears within the application’s response.
Exploiting XXE to Retrieve Files
One common method of exploiting XXE vulnerabilities is to retrieve files from the server’s filesystem. By modifying the submitted XML, attackers can introduce a DOCTYPE element that defines an external entity containing the path to the desired file. They can then edit a data value in the XML returned in the application’s response to utilize the defined external entity.
For example, suppose a shopping application checks the stock level of a product using the following XML:
<?xml version="1.0" encoding="UTF-8"?> <stockCheck> <productId>381</productId> </stockCheck>
Suppose the application does not implement specific defenses against XXE attacks. In that case, an attacker can exploit the XXE vulnerability to retrieve a sensitive file, such as the /etc/passwd file, by submitting the following XXE payload:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <stockCheck> <productId>&xxe;</productId> </stockCheck>
In this payload, the external entity & XXE is defined to contain the contents of the /etc/passwd file, and it is utilized within the productId value. As a result, the application’s response includes the contents of the file, potentially exposing sensitive system information.
It is important to note that in real-world scenarios, there may be multiple data values within the submitted XML, each of which could be used within the application’s response. To systematically test for XXE vulnerabilities, each data node in the XML should be tested individually, utilizing the defined entity to check if it appears within the response.
Practical
Let’s understand XXE with the help of a practical example.
1. Navigate to the Portswigger lab.
2. Now, click on “View details” next to any product.
3. Intercept the “Check stock” request using Burp Suite.
4. Right-click the request > Send to Repeater.
5. In the repeater tab insert the following external entity definition <!DOCTYPE test [ <!ENTITY xxe SYSTEM “file:///etc/passwd”> ]> between the XML declaration and the stockCheck element.
6. Next, replace the productid number with a reference to this external entity & XXE;
7. Observe that the server displays the contents of the etc/passwd file.
Exploiting XXE to Perform SSRF Attacks
Besides retrieving files, XXE vulnerabilities can also facilitate Server-Side Request Forgery (SSRF) attacks. By defining an external XML entity using a targeted URL, attackers can induce the server-side application to make HTTP requests to any URL accessible by the server.
To exploit an XXE vulnerability for an SSRF attack, attackers need to define an external entity using the desired URL and incorporate the defined entity within a data value returned in the application’s response. This allows them to view the response from the specified URL within the application’s response, establishing two-way interaction with the back-end system.
For instance, consider the following XXE example, where an external entity triggers a back-end HTTP request to an internal system within the organization’s infrastructure:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]>
By manipulating the XML and utilizing the defined entity, attackers can gain access to the response from the internal system, potentially enabling them to gather sensitive information or launch further attacks on internal resources.
It is worth noting that in some cases, attackers may only be able to perform blind SSRF attacks, where they cannot directly view the response within the application’s response. However, blind SSRF attacks can still have critical consequences, as attackers can monitor interactions with their controlled systems to gather information or exploit vulnerabilities.
Detecting and Exploiting Blind XXE Vulnerabilities
While some XXE vulnerabilities may not directly expose the values of defined external entities in the application’s responses, attackers can still detect and exploit blind XXE vulnerabilities through advanced techniques.
One approach to exploit blind XXE vulnerabilities is through out-of-band techniques. Attackers can monitor interactions with a system they control, such as an external server or domain. By defining an external entity that references the attacker-controlled system and utilizing it within the XML payload, attackers can indirectly exfiltrate data by observing the interactions made by the target application.
Another method is to trigger XML parsing errors that reveal sensitive data within error messages. Attackers can craft payloads that intentionally cause parsing errors, leading to error messages that contain valuable information. By analyzing these error messages, attackers can extract data such as database connection strings or user credentials.
It is important to note that the attack surface for XXE injection vulnerabilities is often apparent in the application’s HTTP traffic, as it typically includes requests containing data in XML format. However, in some cases, the attack surface may be less visible. By carefully examining requests that do not explicitly contain XML, it is possible to identify hidden XXE attack surfaces.
XInclude Attacks
In certain scenarios, classic XXE attacks may not be feasible due to limited control over the entire XML document. However, attackers might still be able to employ XInclude attacks as an alternative. XInclude is a part of the XML specification that allows the construction of XML documents from sub-documents.
XInclude attacks can be performed when an application receives client-submitted data, which is then embedded into a server-side XML document and subsequently parsed. For example, if client-submitted data is placed into a backend SOAP request, attackers can leverage XInclude to manipulate the data and potentially exploit XXE vulnerabilities.
To execute an XInclude attack, attackers need to reference the XInclude namespace and provide the path to the file they wish to include. Here is an example:
<foo xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include parse="text" href="file:///etc/passwd"/> </foo>
By skillfully incorporating an XInclude attack within any data value of an XML document, attackers can exploit XXE vulnerabilities even when they only control a single piece of data that is injected into a server-side XML document.
XXE Attacks via File Upload
Some applications allow users to upload files that are subsequently processed server-side. While these applications may expect specific file formats like PNG or JPEG, it is crucial to consider the underlying image processing libraries. Certain libraries support XML-based formats like SVG, which can introduce hidden attack surfaces for XXE vulnerabilities.
Attackers can submit malicious SVG images that exploit XXE vulnerabilities, as the SVG format relies on XML. By carefully crafting a malicious SVG image, attackers can target vulnerable XML parsers used during the image processing stage. This technique allows them to trigger XXE vulnerabilities and potentially compromise the application’s security.
XXE Attacks via Modified Content Type
In most cases, POST requests rely on default content types generated by HTML forms, such as application/x-www-form-urlencoded. However, some applications can tolerate different content types, including XML. Attackers can leverage this tolerance to target the hidden XXE attack surface by modifying the content type of the request.
For example, if a normal request uses the following content type:
POST /action HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar
Attackers could potentially submit a modified request with the same result:
POST /action HTTP/1.0 Content-Type: text/xml Content-Length: 52 <?xml version=”1.0″ encoding=”UTF-8″?><foo>bar</foo>
Suppose the application accepts requests containing XML in the message body and parses the content as XML. In that case, attackers can exploit the hidden XXE attack surface by reformatting requests to use the XML format. This technique broadens the scope for potential XXE vulnerabilities beyond explicitly XML-based requests.
How to Find and Test for XXE Vulnerabilities
To identify XXE vulnerabilities effectively, it is recommended to utilize specialized tools such as Burp Suite’s web vulnerability scanner. Burp Suite’s scanner can quickly and reliably detect the vast majority of XXE vulnerabilities, saving time and effort in manual testing.
However, manual testing can still be valuable, especially when confirming and validating vulnerabilities. Here are some manual testing approaches for XXE vulnerabilities:
1. Testing for File Retrieval
To test for file retrieval vulnerabilities, define an external entity based on a well-known operating system file, such as /etc/passwd, and use it within a data value returned in the application’s response. By observing the response, you can determine if the defined entity appears, indicating the presence of an XXE vulnerability.
2. Testing for Blind XXE Vulnerabilities
To test for blind XXE vulnerabilities, define an external entity based on a URL to a system under your control. Monitor interactions with that system to detect any interactions triggered by the application. Burp Collaborator is a useful tool for this purpose, as it allows you to track and analyze interactions with your controlled system.
3. Testing for Inclusion of User-Supplied Non-XML Data
In situations where user-supplied non-XML data is embedded into a server-side XML document, employ XInclude attacks to attempt retrieval of a well-known operating system file. By including an XInclude attack within any data value of the XML document, you can determine if the application is vulnerable to XXE attacks.
It is essential to remember that XML is not only prone to XXE vulnerabilities but can also be vulnerable to other types of attacks such as Cross-Site Scripting (XSS) and SQL injection. Therefore, comprehensive testing should cover all XML-based functionalities for a thorough security assessment.
Preventing XXE Vulnerabilities
To effectively prevent XXE attacks, it is crucial to disable potentially dangerous XML features in the application’s XML parsing libraries or platform APIs. By disabling features such as external entity resolution and XInclude support, the attack surface for XXE vulnerabilities can be significantly reduced.
Configuration options or programmatically overriding the default behavior of XML parsing libraries or APIs can help in disabling unnecessary capabilities. Consult the documentation specific to your XML parsing library or API for detailed instructions on disabling these features.
By implementing these preventive measures, you can significantly reduce the risk of XXE vulnerabilities and protect your applications from potential attacks.
TL;DR
XML External Entity Injection (XXE) vulnerabilities pose a significant threat to the security of web applications. By understanding the nature of XXE attacks, how they arise, and the various exploitation techniques, you can take proactive steps to detect, prevent, and mitigate these vulnerabilities. Regular security assessments, including automated scanning tools and manual testing, are essential for maintaining robust application security. By following best practices and staying informed about emerging threats, you can safeguard your applications and protect sensitive data from XXE attacks. Remember, prevention is key in the ever-evolving landscape of web security. Stay vigilant, be proactive, and prioritize the security of your applications.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.
“Join us on our journey of growth and development by signing up for our comprehensive courses.“
