For this vulnerability, all of the provided material is within this course from Portswigger Web Academy here. I also added in the information provided by OWASP to get a solid understanding of this vulnerability.

OWASP

To start this off, we need a solid understanding of this vulnerability before we do anything else. We will start by looking at the threat agents and attack vectors provided here. 

“Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.”

So when we look for this vulnerability this gives us a good understanding of what to look for that would enable this vulnerability to be present within a web application. Now we will take a look at what OWASP has to say in regard to the impact of this vulnerability.

“These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks. The business impact depends on the protection needs of all affected applications and data.”

We can see that this vulnerability is a pretty invasive and potentially critical vulnerability to have on any web application. Now we will look into some of the things to look for when searching for this vulnerability in the wild.

The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.

• Any of the XML processors in the application or SOAP-based web services have document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by the processor, it is good practice to consult a reference such as the OWASP Cheat Sheet ‘XXE Prevention’.
• If the application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions and may be vulnerable.
• If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework. Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack

Now that we have a good base understanding of this vulnerability and the key areas to look for when hunting for these vulnerabilities, we will move over to PortSwigger to get an example of what this vulnerability may look like as well as get even more familiar with this vulnerability.

PortSwigger

How do XXE vulnerabilities arise?

XXE vulnerabilities arise because the XML specification contains various potentially dangerous features, and standard parsers support these features even if they are not normally used by the application.

Types of XXE

• Exploiting XXE to retrieve files, where an external entity is defined containing the contents of a file, and returned in the application’s response.
• Exploiting XXE to perform SSRF attacks, where an external entity is defined based on a URL to a back-end system.
• Exploiting blind XXE exfiltrate data out-of-band, where sensitive data is transmitted from the application server to a system that the attacker controls.
• Exploiting blind XXE to retrieve data via error messages, where the attacker can trigger a parsing error message containing sensitive data.

How to identify XXE

Testing for file retrieval by defining an external entity based on a well-known operating system file and using that entity in data that is returned in the application’s response.

• Testing for blind XXE vulnerabilities by defining an external entity based on a URL to a system that you control, and monitoring for interactions with that system. Burp Collaborator client is perfect for this purpose.
• Testing for vulnerable inclusion of user-supplied non-XML data within a server-side XML document by using an XInclude attack to try to retrieve a well-known operating system file.