In this article, I will address XML External Entities vulnerabilities in .NET and the potential impact that it can have on your platform. By the end, you can expect to have a basic understanding of XML External Entities, how to find them, and what mitigation strategies are at your disposal to deal with this vulnerability.
We will explore how to implement solutions to XML External Entities attacks on the ASP.NET Core development stack. This means that to get the most out of this article, you need some experience working with C# and ASP.NET. If you are only interested in XML External Entities, we've written a number of articles focused on a variety of technology stacks.
With that out of the way, let's dive in.
XML External Entities
Let's start by explaining what XML External Entities are.
XML, or Extensible Markup Language, is a markup language and file format for storing, transmitting, and reconstructing arbitrary data. In addition, this language is used in the programming world to define rules for encoding documents in a format that is both human-readable and machine-readable.
Alright then, but how can a file structure become a threat to your application?
By default, XML processing tools allow the specification of an external entity, a URI, retrieved and processed during the XML file parsing. This parser can then request and embed the content on the specified URI inside the XML document. And that represents an open door for attacks since an attacker could leverage this property as an avenue to retrieve any resource.
In a nutshell, an XML External Entities attack, or XXE injection, is an attack that takes advantage of XML parsing vulnerabilities. It targets systems that use XML parsing functionalities that face the user and allow an attacker to access files and resources on the server. XXE injection attacks can include disclosing local files containing sensitive data, such as passwords or private user data using file: schemes or relative paths in the system identifier.
Given all this, it should be pretty apparent that any tenacious bad actor could potentially take over your server.
How to Spot XML External Entities
All that sounds pretty concerning. But what does it actually look like?
Let's look at a simple example in action.
Here's a sample XML document containing an item XML element.
<item id="1">
<title>Toilet Paper</title>
</item>Alright, but where's the external entity?
We add external XML entities by using a system identifier within a DOCTYPE header. The purpose of this header is to add a few more properties to the XML file structure.
For example, the code below contains an external XML entity that would try to connect to an internal website. This is not ordinarily accessible for users.
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://myinternalwebsite"> ]>
<item id="1">
<title>&xxe;</title>
</item>That is terrible news.
As mentioned before, these entities can access local or remote content on your server. And if you keep sensitive files on the server, those sensitive files will be vulnerable. You could be providing a path that an attacker can use to gain control of your website.
Likewise, other XML External Entities attacks can access local resources that may do even more than return data. This is a common avenue for denial of service attacks.
How to Mitigate XML External Entities Vulnerabilities
With all the definitions out of the way, what can you do to fix this issue on your platform?
I have good news for you. Mitigating XXE injection vulnerabilities is very simple.
Allow me to briefly refer to a previous article on the general approach as a quick refresher.
"Generally, as long as you are not intentionally trying to open a window for the vulnerability and consider that you need the functionality of loading user-provided XML files, you don't have to worry much about this issue."
"Let's illustrate."
"As we have mentioned, if an application has an endpoint that parses XML files, an attacker could send a specially crafted payload to the server and obtain sensitive files. The files the attacker can get depend heavily on how you set up your system and how you implement user permissions."
"So, to prevent this situation from playing out, first, don't use libraries that support entity replacement."
Thankfully, there's no popular library in .NET with such an issue.
Odds are that you are using something like XmlDocument or XmlReader, which both come with protections against such vulnerabilities baked in and the feature of external entities disabled by default.
Below is an example of a default, protected implementation:
public string xml_to_text(xml) {
var xml_doc = new XmlDocument();
xml_doc.LoadXml(xml); return xml_doc.InnerText;
}Now, suppose your application actually requires using external entities for some necessary features. In that case, one approach you can take to minimize the potential for exploits is to safelist known external entities.
Other Strategies
Some other strategies to mitigate XXE Injection attacks include the following:
Use fewer complex data formats like JSON and avoid serialization of sensitive data.
Patch or upgrade all XML processing code and libraries in your application.
Verify that XML file upload validates incoming XML using XSD validation.
Update SOAP to SOAP 1.2 or higher.
Use SAST tools to help detect XXE in source code.
Lastly—and I really want to emphasize this—do not parse XML unless it's an application requirement. There are many ways to offer these functionalities without using these libraries.
And as we have said before, in the end, the best mitigation strategy is to not be open to vulnerabilities in any way.
Moving on
Providing robust and secure services is becoming more and more complicated. Projects of that caliber now require a significant investment of time and extensive expertise. And your organization might not be able to afford that cost.
Now, if you are responsible for a team of competent and productive members focused on delivering speedy and innovative solutions, we recommend our Dynamic Application Security Testing (DAST) suite. Our DAST tool tests a running version of your application to identify potential security vulnerabilities. This will allow you to have real-time, reliable, and detailed reports about the security status of your platform. Our product ensures that you get the best insight and tools to provide reliable decision-making information so that you can go back to focusing on your work.
You can check it out here.
This post was written by Juan Reyes. Juan is an engineer by profession and a dreamer by heart who crossed the seas to reach Japan following the promise of opportunity and challenge. While trying to find himself and build a meaningful life in the east, Juan borrows wisdom from his experiences as an entrepreneur, artist, hustler, father figure, husband, and friend to start writing about passion, meaning, self-development, leadership, relationships, and mental health. His many years of struggle and self-discovery have inspired him and drive to embark on a journey for wisdom.
