Welcome back, my aspiring Web App cyberwarriors!

Among the most important types of web app attacks is the XXE attack. This is the XML eXternal Entity Injection attack. This type of vulnerability allows an attacker to interfere with the app’s processing of XML data. Many applications use the XML format to transmit data between the browser and the server. The attack occurs when the web app references data in an external entity using XML to transfer the data.

This attack allows the attacker to access or view files on the back-end server filesystem or other data that the application can access.

What is XML?

XML stands for Extensible Markup Language. XML is a markup language for describing a structured document format. XML has many similarities to HTML, but it is stricter in it definition to simplify its parsers and enhance security. XML is designed to be both human and machine readable and used primarily to transfer data between applications.

Let’s look at how an XXE attack can be exploited to reveal confidential data on the server.

Step #1: Open Kali and OWASP-BWA

The first step is fire up Kali in one VM and the OWASP-BWA in the other.

Now open the browser in Kali and navigate to the IP address of the OWASP-BWA and click on the OWASP Mutillidae II web application.

Go to the Others tab on left and then XML External Entity Injection and XML Validator as seen below.

This will open the XML validator like this.

Step #2: Add XML to the Validator

The XML validator is intended to check whether your XML is properly formed. If it is, the validator will display the contents of the XML below. You can place anything into the XML window and then click on the Validate XML button beneath it to determine whether your XML is properly formed.

Here we will enter some simple XML with a message and if it is formed properly, the message is displayed below beneath the XML. If not, the XML validator will display an error message

Let’s see whether we can manipulate this functionality to inject some malicious XML to retrieve resources on the web server.

Step #3: Open BurpSuite and Set Up Proxy

Next, let’s open the BurpSuite and set up the proxy in our browser.

Now, enter our properly formed XML and intercept the request in the Proxy like below.

We can see where the XML parser converted the XML into the URL.

What if we could send malicious XML requesting files or other resources on the server? Could we retrieve sensitive files by requesting them using XML? Let’s try.

Let’s create some XML that requests that /etc/passwd file from the web server such as;

<?xml version=”1.0″ “?>

<!DOCTYPE change log [

<!ENTITY systemEntity SYSTEM “../../../../etc/passwd” >]>

<change log><text>&systemEntity;

</text></change-log>

Now open the Decoder tab in BurpSuite and enter this XML like below. Next, click on the Encode as… button and a drop down menu will appear.

Since we want to place this XML into a URL, select URL encoding

This will encode (translate) our XML into a form we can use in the URL that will request the resources.

Step #4: Place the Encoded XML into the URL

Now, go back to the BurpSuite Proxy and copy and paste the encoded XML into the URL of the GET request from the browser. Make certain to place it exactly where the original XML has been, such as seen below.

Now, forward the packet to the Mutilldae II application.

You should see the following at the application. First, the submitted XML and then the contents of the /etc/passwd file of the web server!

The XML had requested the /etc/passwd file and the parser granted us access. Of course, this could have been any resource on the web server.

Summary

Many web application use XML to transfer data from the browser and server. If the attacker can create well-formed XML and inject it into the request, it may be able to access external data on the web server or other resources.