Xml External Entities in Aspnet (Csharp)

XML External Entity (XXE) injection occurs when an application processes XML input that references external entities, and this risk is present in ASP.NET applications that deserialize XML in C#. If an ASP.NET endpoint accepts XML payloads—such as SOAP messages, configuration uploads, or legacy web service inputs—and uses .NET XML parsers without disabling external entity resolution, an attacker can leverage external entities to read local files, cause SSRF, or enumerate internal resources.

In C#, common entry points include XmlDocument, XmlReader, and XDocument when configured without secure settings. For example, using XmlDocument with default settings allows the parser to resolve external DOCTYPE declarations, which can be abused to load file:// URLs or trigger HTTP requests to attacker-controlled endpoints. A vulnerable pattern looks like this:

// Vulnerable: XmlDocument processes external entities by default
var xml = new XmlDocument();
xml.LoadXml(requestBody); // requestBody contains external entity references
var value = xml.SelectSingleNode("//data")?.InnerText;

An attacker can supply a payload such as:

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

If the XML parser resolves the external entity, the contents of /etc/passwd may be included in the response or exfiltrated via a secondary channel. ASP.NET applications that use WCF with custom bindings or legacy ASMX services may also be affected when XML deserialization is enabled without appropriate safeguards. Because ASP.NET often runs with elevated trust in certain hosting configurations, successful XXE can lead to sensitive file disclosure and potential lateral movement within the runtime environment.

Beyond file disclosure, XXE can be chained with SSRF by directing external entity references to internal metadata services or local network services. For example, an external entity pointing to http://169.254.169.254/latest/meta-data/ can expose cloud instance metadata if the host is reachable from the parser. This amplifies the impact within cloud-hosted ASP.NET services. The vulnerability remains relevant when input validation is weak and XML processing is not explicitly hardened, even when using newer APIs that still rely on underlying .NET XML stacks.

Securing XML processing in C# requires disabling external entity resolution and restricting DTD processing. The most effective approach is to use secure settings on the XML parser and avoid legacy APIs where possible. For XmlDocument, you can configure an XmlReaderSettings object that disables DTD processing and external entities, then use it to create an XmlReader for controlled parsing.

// Secure: XmlReader with DTD and external entity processing disabled
var settings = new XmlReaderSettings
{
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};
using (var reader = XmlReader.Create(new StringReader(requestBody), settings))
{
    var xml = new XmlDocument();
    xml.Load(reader);
    var value = xml.SelectSingleNode("//data")?.InnerText;
}

For LINQ to XML (XDocument), you can achieve similar safety by using an XmlReader with the same settings:

// Secure: XDocument via XmlReader with restricted settings
var settings = new XmlReaderSettings
{
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};
using (var reader = XmlReader.Create(new StringReader(requestBody), settings))
{
    var doc = XDocument.Load(reader);
    var value = doc.Descendants("data").FirstOrDefault()?.Value;
}

If you must work with XmlDocument directly and cannot change the parsing pattern globally, you can disable external resources by setting the resolver to null before loading, though using XmlReader is preferred:

// Partially safer: XmlDocument with resolver disabled
var xml = new XmlDocument();
xml.XmlResolver = null;
xml.LoadXml(requestBody);

In ASP.NET Web API or MVC, additional mitigations include validating incoming content types and rejecting XML when JSON or other safer formats suffice. For SOAP services, consider migrating to modern stacks that rely on JSON or explicitly configure secure bindings. Regularly scan your API surface with middleBrick to detect XXE and related issues; the scanner checks XML processing configurations as part of its Input Validation and Property Authorization checks. If your organization requires continuous assurance, the middleBrick Pro plan provides ongoing monitoring and CI/CD integration to fail builds when insecure XML handling is detected.