Xml External Entities in Aspnet

In ASP.NET applications, XML External Entity (XXE) vulnerabilities typically arise when user-controlled XML input is processed without proper restrictions on external entity resolution. This commonly occurs in ASP.NET Web API endpoints, WCF services, or ASP.NET MVC controllers that deserialize XML using XmlSerializer, XDocument.Load(), or XmlReader with default settings that allow DTD processing and external entity resolution.

A classic ASP.NET-specific pattern involves accepting XML payloads in POST requests to API controllers, such as a user profile update endpoint that expects XML:

// Vulnerable ASP.NET Core Web API controller
[HttpPost("update-profile")]
public IActionResult UpdateProfile([FromBody] string xmlData)
{
    var serializer = new XmlSerializer(typeof(UserProfile));
    using (var reader = new StringReader(xmlData))
    {
        // Default XmlReaderSettings allows DTD processing
        var profile = (UserProfile)serializer.Deserialize(reader);
        return Ok();
    }
}

If an attacker submits XML containing an external entity referencing a local file (e.g., <!ENTITY xxe SYSTEM "file:///c:/windows/system32/drivers/etc/hosts">), the ASP.NET XML parser may resolve and include the file contents during deserialization, leading to information disclosure. In .NET Framework, XmlTextReader or XmlDocument.LoadXml() with default XmlReaderSettings also permit external entity resolution unless explicitly disabled.

Another ASP.NET-specific vector is in SOAP-based WCF services where the basicHttpBinding or wsHttpBinding processes incoming SOAP messages. If the service uses XmlSerializer for message formatting and does not restrict DTDs, XXE can be triggered via malicious SOAP headers or body elements. This is particularly relevant in legacy ASP.NET ASMX services or WCF services hosted in IIS.

XXE in ASP.NET can also lead to SSRF (Server-Side Request Forgery) if the external entity references an internal HTTP endpoint (e.g., <!ENTITY xxe SYSTEM "http://localhost:8080/internal-admin">), potentially allowing attackers to probe internal networks or access admin interfaces not exposed externally.

Detecting XXE in ASP.NET applications requires analyzing how XML input is handled across common ASP.NET components. Manual code review should focus on:

• ASP.NET Web API controllers using [FromBody] with string or custom types deserialized via XmlSerializer
• ASP.NET MVC controller actions accepting XML via Request.InputStream or HttpRequest.Form
• WCF service implementations using XmlSerializer or DataContractSerializer with unsafe settings
• ASP.NET Web Forms pages using XmlDocument.Load() on user-supplied input
• Any use of XDocument.Load(), XElement.Load(), or XmlReader.Create() without disabling DTD processing

middleBrick detects XXE vulnerabilities in ASP.NET APIs through black-box scanning by sending specially crafted XML payloads containing external entity references. It tests for both file disclosure and SSRF vectors by monitoring for:

• Responses containing unexpected file contents (e.g., web.config, appsettings.json)
• Changes in response behavior indicating successful entity resolution (e.g., altered response time, error messages)
• Outbound HTTP requests to internal or external domains indicating SSRF

The scanner sends payloads such as:

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY test SYSTEM "file:///c:/windows/win.ini">
]>
<root>&test;</root>

If the ASP.NET API reflects the contents of win.ini in the response, middleBrick flags an XXE vulnerability. It also tests for blind XXE via out-of-band interactions (OAST) when direct reflection is not observed, detecting whether the server makes HTTP requests to attacker-controlled domains.

middleBrick’s scan includes XXE as part of its "Input Validation" and "Data Exposure" checks, providing specific evidence such as the malicious payload sent, the observed response containing external data, and the affected endpoint (e.g., POST /api/user/profile). The scanner does not require authentication and tests the unauthenticated attack surface, making it effective for identifying XXE in publicly accessible ASP.NET APIs.

Fixing XXE in ASP.NET applications involves disabling DTD processing and external entity resolution in all XML parsing operations. The approach varies slightly depending on the ASP.NET technology and XML API used.

For XmlSerializer in ASP.NET Core or .NET Framework, use XmlReaderSettings to prohibit DTDs:

// Secure ASP.NET Core controller
[HttpPost("update-profile")]
public IActionResult UpdateProfile([FromBody] string xmlData)
{
    var serializer = new XmlSerializer(typeof(UserProfile));
    var settings = new XmlReaderSettings {
        DtdProcessing = DtdProcessing.Prohibit, // Critical setting
        XmlResolver = null // Prevents external resolution
    };
    using (var reader = XmlReader.Create(new StringReader(xmlData), settings))
    {
        var profile = (UserProfile)serializer.Deserialize(reader);
        return Ok();
    }
}

When using LINQ to XML (XDocument, XElement), explicitly create an XmlReader with secure settings:

var settings = new XmlReaderSettings {
    DtdProcessing = DtdProcessing.Prohibit
};
using (var reader = XmlReader.Create(new StringReader(userXml), settings))
{
    var doc = XDocument.Load(reader);
    // Process doc safely
}

For XmlDocument (legacy ASP.NET), set XmlResolver to null and disable DTD processing via XmlReaderSettings when loading:

var settings = new XmlReaderSettings {
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};
using (var reader = XmlReader.Create(new StringReader(xmlInput), settings))
{
    var doc = new XmlDocument();
    doc.Load(reader);
}

In WCF services, configure the XmlSerializerFormatAttribute or use a custom BehaviorExtensionElement to enforce secure reader settings. For ASP.NET Web Forms, avoid loading XML from user input; if necessary, apply the same XmlReaderSettings restrictions.

Additionally, validate XML input against a strict schema (XSD) that excludes DOCTYPE declarations. Implement input validation to reject XML containing a <!DOCTYPE string. However, validation alone is insufficient—always configure the XML parser to disable external entity resolution as the primary defense.

After applying fixes, verify with middleBrick by rescanning the API. The scanner should no longer detect XXE vulnerabilities, confirming that external entity resolution is properly restricted.