XML Injection

XML (eXtensible Markup Language) is a widely used format for storing and exchanging data on the web. However, like any technology, it's susceptible to vulnerabilities if not implemented securely. One such vulnerability is XML injection, a type of attack where an attacker exploits vulnerabilities in XML parsers to manipulate or access sensitive data. In this article, we'll delve into what XML injection is, explore some examples, understand its risks, and discuss prevention techniques.

What is XXE (XML External Entity) Injection

XXE is a classification of an attack that is simple to perform and that has devastating results. More specifically by performing XXE attacks on applications we are able to do the following:

• A denial-of-service attack on the system

• A Server-Side Request Forgery (SSRF) attack

• The ability to scan ports from the machine where the parser is located

• Exfiltration of sensitive data

This type of attack relies on improperly configured XML parsers within an applications code.

All XXE vulnerabilities arise on applications that have endpoints that accept XML or XML like payloads(SVG, HTML/DOM, PDF (XFDF) and RTF).

The attack leverages a special annotation that is in the XML specification which is used to import external files. This annotation is described in section 4.2.2 of the XML specification that can be found here: https://www.w3.org/TR/xml/

If the annotation is processed by the application due to an improperly configured parser an attacker is then able to do two things:

1. Import files that are hosted on the server that the application is hosted by referencing them in the request.

2. Perform Server Side requests by referencing an internal URL. Thereby being able to reach all the servers and applications that the target application was able to.

What are External Entities

In XML processing, an External Entity can be an XML element that references an external source (e.g., a file or a URL). If not handled securely, an XXE vulnerability can occur, allowing attackers to exploit these entities to access or manipulate external files and potentially perform malicious server side actions.

Example of referencing an External Entity through supplying an XML XXE payload:

Figure showing an example of a XXE attack payload

In the above example we are referencing the file that is located in /etc/passwd which represents a file with sensitive information.

By supplying the payload above we are trying to import this file in the description part of the supplied books object. Making it so that if the application reflects to us the supplied information, it would then show all the contents of the file /etc/passwd in the description of the supplied book.

Since most Java XML parsers have XXE(External Entities) enabled by default, Java is thought to be especially vulnerable to XXE attacks. To defend against this attacks we must explicitly disable XXE(External Entities) to use these parsers safely.

To understand the vulnerability better lets see an exploitation scenario in a test application that was created in a CTF (Capture The Flag) challenge format.

Resource to learn more about external entities:

CTF challenges: Cybersecurity challenge, where the challenge creator has created web applications that contain one or more vulnerabilities. The applications are built in such manner to enable participants the ability to exploit the vulnerabilities within them, with the goal of obtaining sensitive information that is contained in the applications. The sensitive information is represented by a “flag” which is basically a text string. Where if one manages to extract this text, it is then considered that the participant has solved the challenge.

Performing XXE attack to retrieve the flag

First to login in the application we will use the default credentials:

admin:admin

When inspecting the code of the test application, we can see that a weakly configured SAX Parser is being used to parse the user supplied XML input.

This occurs due to the SAX Parser having External Entities processing enabled by default.

Figure showing the intialization of the weakly configured SAX Parser that is vulnerable to XXE attacks

From the above we can determine that the application is vulnerable to XXE (XML External Entity Injection)

We see that we can upload XML input in the “/upload” endpoint.

Figure showing the response after requesting the upload route

Let’s upload a malicious XML input.

Figure showing the used malicious XML XXE payload

We are trying to obtain the flag that is located in /project/flag , we know where it is located through the Dockerfile of the application that would be supplied when trying to solve this challenge.

FROM maven:3-openjdk-8 as build
RUN mkdir /usr/src/project
COPY . /usr/src/project
WORKDIR /usr/src/project
RUN mvn package -DskipTests
# CMD mvn spring-boot:run
FROM openjdk:8u181-jdk-alpine
RUN mkdir /project
COPY --from=build /usr/src/project/target/xxe-vulnerable-app.jar /project/
COPY ./flag /project/
WORKDIR /project
CMD java -jar xxe-vulnerable-app.jar

More specifically from the lines:

COPY ./flag /project/
WORKDIR /project

As we can see from above, we are defining an external entity which references the file location of the flag in the description tag so it will be included in the response when we ask to retrieve all the books information in the database.

We can see that when we go to retrieve all the book information from the “/books” route, we can find the flag in the description of the book we uploaded:

Figure showing the acquistion of the flag subsequent to the submission of the malicious payload.

Flag obtained: FLAG{Br3ACH3D-R3Ally-AGAIN}

Link to vulnerable application: https://github.com/Iason-Tzortzis/XXE-Vulnerable-Application

Defending against XXE (External Entity injection)

The safest way to prevent XXE is always to disable DTDs (External Entities) processing completely when configuring the XML parser.

In the case of this challenge to configure the SAX Parser to not process External Entities we would include the following lines of code in our project:

factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
saxParser.getXMLReader().setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

To find more information about how to defend against XXE attacks we can use the OWASP XML External Entity Prevention Cheat Sheet which can be found here:

XML External Entity Prevention - OWASP Cheat Sheet SeriesWebsite with the collection of all the cheat sheets of the project.cheatsheetseries.owasp.org

The cheet sheet has information about most of the programming languages and the XML parsers that can be used in them and it shows how to properly configure them to prevent this type of attacks from happening.

Summary

XXE attacks are simple to understand and perform but they are also easy to defend against. This type of vulnerability usually arises in applications because they it is not known by most developers and because of the fact that in most cases External Entities processing is by default enabled in most parsers. The combination of the two reasons makes a recipe for disaster. That being said, it is important to always test for these types of attacks in new and old applications , as a single missing configuration line in an XML parser can result in so much damage.