security | privacy | web dev

OWASP Top 10: XML External Entities (XXE) (A4:2017)

22nd July 2020 ‧ By Simon Bell ‧ Category: Web Application Security

4 min read

Picture of a server rack

Photo by Taylor Vick

This is part of my OWASP Top 10 series covering the top 10 most critical web application security risks. If you've missed any of the previous security risks, check out the intro and overview.

Risk Rating

Exploitability: 2
Prevalence: 2
Detectability: 3
Technical: 3
Threat Agents
Weakness Prevalence
Weakness Detectability
Technical Impacts
Business Impacts
Application Specific
Easy: 3
Widespread: 3
Easy: 3
Severe: 3
Business Specific
Average: 2
Common: 2
Average: 2
Moderate: 2
Difficult: 1
Uncommon: 1
Difficult: 1
Minor: 1
OWASP's Risk Rating Methodology

What are XML External Entities?

An XML external entity injection (XXE) involves an attacker interfering with how an application processes an XML file. The attacker might submit XML code that references an external entity, such as a hard drive. If the application is vulnerable to an XXE attack then its XML parser might be tricked into leaking sensitive data to the attacker.

In XML terminology, an entity is defined as a storage unit of some type. There are different types of entities, but essentially external general/parameter parsed entity (often shortened to external entity) can access local or remote content via a declared system identifier (typically a URI).

The real danger of XXE injections is if an attackers escalates the attack to compromise the underlying server or other aspects of the back-end infrastructure. This could happen, for example, if the attacker uses the XXE vulnerability to perform a server-side request forgery (SSRF) attack.

Examples of XML External Entities

Let's say Mallory visits a website that allows XML files to be uploaded and processed. She uploads the following file:

<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

If the XML parser is susceptible to an XXE injection attack, then it may return the contents of /etc/passwd (a file found on Unix-like systems containing a list of system accounts) to Mallory.

Let's see another example. This time Mallory uploads the following XML file:

<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "" >]>

If vulnerable, this injection will probe the web server's private network which may reveal sensitive information to Mallory.

In our final example, Mallory uploads the following XML file:

<?xml version="1.0" encoding="ISO-8859-1"?>
  <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]>

On Unix-like systems /dev/random contains an endless supply of random data (designed for pseudorandom number generators). As a result, this XML file may cause a denial-of-service attack.

What's the impact of XML External Entities?

As we saw in our examples, XXE injection attacks can be used to extract sensitive data, execute a remote request from the server, scan internal systems, perform a server-side request forgery (SSRF) attack, carry out a denial-of-service attack, and may other types of attacks.

The impact of these attacks may be the loss of sensitive data, an attacker may carry out identity fraud, sell the data on underground markets, etc.

How to defend against XML External Entities

Try to avoid using XML parsers to process data. Instead use format such as JSON which are more simple and less prone to such vulnerabilities. Also, avoid serialising sensitive data in the first place to reduce risks.

Make sure any XML processors and libraries are patched and updated to mitigate XXE injection attacks. Use dependency checkers and update SOAP to SOAP 1.2. Also, disable the processing of XML external entity and Document Type Definition (DTD).

Essentially, XXE vulnerabilities arise because an application's XML parser allows potentially dangerous features that are neither used nor needed. The easiest way to prevent such XXE attacks is to disable those features.

More on OWASP Top 10

Picture of simon bell

Simon Bell

I'm a Web Security Consultant, Full-Stack Secure Web Developer, Researcher, Writer, and Educator. I recently passed my Cyber Security PhD viva (subject to amendments) and I have a BSc in Computer Science.

This website is where I enjoy writing about security, privacy, and web development.

Connect with me at:

Join the Key Threat Community

Every week I share:

  • A roundup of important cybersecurity news stories
  • Summary of popular cybersecurity content from Twitter
  • The latest security, privacy, and web info from Key Threat
Up arrow Back to top