Working with XML is often far more dangerous than most developers want to admit. Because XML files can contain references to other XML files, it is susceptible to an attack known as XML External Entity Injection. David Petty describes this as,
XXE arises when an application resolves arbitrary external entities defined in an XML document. External entities are like macros that expand to a local or remote resource through a system identifier. This identifier is assumed to be a URL that the XML parser processes, and then all instances of the external entity within the XML document are replaced with the contents of the external resource. An attacker can exploit this to obtain sensitive data on the application’s machine or perform remote code execution.
Another vulnerability cited by Petty is XML DTD Validation:
A security problem arises if the server’s XML parser accepts an arbitrary external DTD URL and attempts to download the DTD and validate the XML document against it. In this case, an attacker could input any URL and execute a Server Side Request Forgery (SSRF) attack where the attacker forces the server to make a request to the target URL. The server may have privileges to access certain resources that the attacker doesn’t, and the attacker can leverage this to scan and attack services behind the server’s firewall. A summary of SSRF can be found here.
To avoid these vulnerabilities, .NET developers were taught to use the XmlSecureResolver class. And that was perfectly acceptable in the .NET Framework era. But in .NET Core, it offers no protection. Levi Broderick explains,
The class System.Xml.XmlSecureResolver does not work correctly in .NET. It relies on Code Access Security (CAS), but the CAS infrastructure was never ported from .NET Framework to .NET Core. The end result is that the type no-ops, allowing resolution which should be blocked.
He goes on to explain it is impossible to fix this and as a result XmlSecureResolver in .NET 6 and earlier fails dangerously. To resolve this, in .NET 7 the class was marked as obsolete and any attempts to use it will unconditionally throw an exception.
Since XML parsing is still important, Microsoft has instead introduced the ThrowingResolver. This version of XmlResolver will always prevent external entity resolution. This may seem rather heavy-handed, but in practice most applications that parse XML don’t need external entity resolution. In the rare cases you do, you can create a custom XmlResolver as explained by Adriano Repetti.
