The purpose of this article is to serve as a guide for and to provide examples of XML External Entities vulnerabilities for the React tech stack and the potential impact it can have on your security. We'll address the following topics:
What XML External Entities are
How to spot them on your platform
What mitigation techniques you can use against them
What tools you can leverage to improve your security
It's crucial to emphasize that we will be exploring XML External Entity attacks in the context of the React development stack. So, to get the most out of this article, you need experience with JavaScript and the React platform.
What Are 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. In the process of file parsing, XML processing code can retrieve these external entities without validation. Attackers can circumvent your security measures by requesting and embedding the content on the specified external entity inside the XML document. This is essentially an open back door. 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.
In essence, this vulnerability could render your server insecure given enough persistence and time.
Looking for XML External Entities
The following example is a bare-bones XML document containing an item XML element.
<item id="1">
<title>Toilet Paper</title>
</item>Great, but where's the external entity?
You would represent an external entity by using a system identifier within a DOCTYPE header.
<!ENTITY xxe SYSTEM "https://www.google.com" >]>The purpose of this header is to add more properties to the XML data structure. To illustrate this further, the code below contains an external XML entity that would try to compromise a potentially perpetual file.
<!ENTITY xxe SYSTEM "file:///gkr/rand" >]>
<item id="1">
<title>&xxe;</title>
</item>This attack would result in a denial of service (DoS) attack and bring your server to its knees. Yikes!
As we've mentioned in other articles, these entities can access local or remote content, so you need to protect the sensitive files on the server.
By not doing so, you could potentially provide an attacker with a way to gain control of your website. Game over. By no means is this a thorough explanation of XML External Entities or XXE attacks. Exploring all the complexities of this vulnerability is beyond the scope of this article.
A Simple Way to Mitigate React XML External Entities
Alright, now to the practical part: how can you fix this mess?
Thankfully, most of the work has already been done for you.
As a quick refresher, and for the sake of brevity, I'll briefly refer to a previous article on the recommended approach to take.
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.
Luckily, JavaScript has no popular XML parsing libraries with such a problem.
Generally, you have done most of the work as long as you keep your libraries updated. Your application is likely implementing react-xml-parser, which already comes with protections against this vulnerability. Additionally, for most libraries, external entities are disabled by default.
A straightforward example of a protected implementation on React would be the following:
var XMLParser = require('react-xml-parser');
var xml = new XMLParser().parseFromString(xml_text);console.log(xml);Additionally, if your platform does require the use of external entities, you can safelist known external entities to minimize the potential for exploits.
Other Strategies
Here are some other strategies you can take to mitigate XXE Injection attacks:
Use simpler 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.
Finally, as a rule of thumb, do not implement the processing of XML unless it's an application requirement. There are numerous ways to offer similar features without opening your application to threats.
The most practical mitigation approach to vulnerabilities is to not be open to them in the first place.
What Now?
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 it.
If you're 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 provide real-time, reliable, and detailed reports of 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.
