Today XML External Entities (XXE) vulnerabilities are still ubiquitous, despite the fact that recommendations to protect against them have been an integral part of security standards for years. In this post, the first in a series of three blog posts, we will try to demystify XXE vulnerabilities and present the rule we put in place to help you detect and prevent them.
An XML entity is declared in the Document Type Definition (DOCTYPE) of an XML document. An entity is internal, if its value is retrieved from inside the document, or external if its value is a URI. When an entity reference is subsequently used in the XML document, the reference is replaced by the value that was retrieved for it. For example, the following XML document retrieves the value of the xxe entity via URI from a file which content is then embedded into the document:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE person [
<!ENTITY internal "Matt">
<!ENTITY xxe SYSTEM "file:///data/city.txt">
]>
<person>
<name>&internal;</name>
<city>&xxe;</city>
<age>18</age>
</person>
An application dealing with XML files should be careful to restrict external entities to authorized file system and network resources, otherwise it opens the door to arbitrary file disclosures and server-side request forgery (SSRF) attacks:
<!DOCTYPE person [
<!ENTITY file SYSTEM "file:///etc/passwd">
<!ENTITY ssrf SYSTEM "https://internal.network/sensitive_information">
]>
Note: an entity can be general, as shown above, or it can be a parameter entity. The only difference between the two is that parameter entities are defined and used exclusively in the DTD.
To help developers on that topic, rule S2755 “XML parsers should not be vulnerable to XXE attacks” is available for C#, Java, JS/TS, Python, PHP, and C/C++ in SonarLint, SonarCloud and all editions of SonarQube.
This rule raises an issue whenever the XML processor is misconfigured even when it only parses trusted XML files. We believe that there are only advantages to controlling and limiting the use of external entities:
Not convinced? Take a look at some actual and severe vulnerabilities, found by S2755 in various well-known open source projects written in different programming languages:
Keep these things in mind when assessing XXE vulnerability issues in your own projects:
In this post we saw examples of XXE vulnerabilities in popular and various open source projects written in different programming languages. I explained how to assess XXE vulnerability issues and what are the benefits of rule S2755, but only you can prevent vulnerabilities, so next time we’ll discuss how to fix them