Xml Bomb in Aspnet

An XML bomb (also known as a billion laughs attack) exploits recursive entity expansion in XML parsers to consume excessive memory or CPU. In ASP.NET applications, this typically occurs when user-supplied XML is parsed without proper safeguards, such as in API endpoints that accept XML payloads for data import, configuration updates, or webhook processing.

Common vulnerable code paths in ASP.NET include:

• ASP.NET Web API controllers using XmlSerializer or XDocument.Load() on raw request bodies without input limits.
• ASP.NET Core minimal APIs that deserialize XML via System.Text.Json with XML input formatters (though less common, misconfiguration can still expose risk).
• Legacy ASMX web services or WCF services that automatically deserialize XML using XmlSerializer with default settings.
• Middleware or handlers that log or process XML from headers (e.g., Content-Type: text/xml) without validating size or structure.

For example, a simple ASP.NET Core API endpoint that accepts XML for user data import might look like this:

[HttpPost("import")]
public IActionResult ImportUsers([FromBody] XmlDocument xmlDoc)
{
    // Vulnerable: XmlDocument.LoadXml() processes entities by default
    xmlDoc.LoadXml(Request.Body.ToString());
    // Process data...
    return Ok();
}

If an attacker sends a payload like:

<?xml version="1.0"?>
<!DOCTYPE root [
  <!ENTITY a0 "DoS">
  <!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;"
  <!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;"
  
  <!ENTITY a10 "&a9;&a9;&a9;&a9;&a9;&a9;&a9;&a9;&a9;&a9;"
]>
<root>&a10;</root>

The parser expands &a10; to over one billion copies of "DoS", consuming gigabytes of memory and causing denial of service. ASP.NET's default XML reader settings do not disable entity expansion, making such attacks possible unless explicitly mitigated.

Detecting XML bomb vulnerabilities in ASP.NET requires analyzing both code patterns and runtime behavior. Since the attack happens during XML parsing, static analysis alone may miss context-specific risks (e.g., whether user input reaches the parser). middleBrick identifies this issue through black-box testing of the unauthenticated attack surface, specifically by sending XML payloads with recursive entity definitions and monitoring for abnormal resource consumption or error responses that indicate successful parsing.

During a scan, middleBrick:

• Sends XML payloads containing nested entity references (e.g., up to 10 layers of expansion) to endpoints accepting Content-Type: text/xml, application/xml, or application/xhtml+xml.
• Measures response time and connection behavior — a successful XML bomb often causes timeouts, 500 errors, or connection drops due to resource exhaustion.
• Checks for error messages that reveal XML parsing details (e.g., "Reference to undefined entity" or "Maximum entity expansion limit exceeded"), which can confirm parser vulnerability even if the attack doesn’t fully succeed.
• Correlates findings with endpoint characteristics: XML endpoints in ASP.NET Web API, minimal APIs, or WCF services are flagged for deeper inspection.

For example, if an ASP.NET Core endpoint at /api/data/upload returns a 500 Internal Server Error after receiving a small XML bomb payload (under 1KB), middleBrick reports this as a potential XML bomb vulnerability with high severity, noting that the XML parser attempted to process external entities without limits.

This detection is complementary to code review: middleBrick finds the exploitable surface, while developers must inspect code paths like XmlReader.Create() calls or model binding configurations to confirm the root cause.

Fixing XML bomb vulnerabilities in ASP.NET involves configuring XML parsers to disable dangerous features like DTD processing and entity expansion. The remediation depends on the ASP.NET framework and parsing method used.

For System.Xml.XmlReader (used indirectly by XmlDocument, XDocument, and DataSet):

XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit; // Blocks DOCTYPE entirely
settings.MaxCharactersFromEntities = 1024; // Limits entity expansion size
using (XmlReader reader = XmlReader.Create(inputStream, settings))
{
    XDocument doc = XDocument.Load(reader);
    // Safe to process
}

In ASP.NET Core Web API, if you're using model binding with XML formatters, configure the input formatter in Program.cs:

builder.Services.AddControllers(options)
    .AddXmlDataContractSerializerFormatters()
    .AddXmlSerializerFormatters();

// Then customize the formatter
builder.Services.Configure(options =>
{
    options.UseHttpSharedStream = false;
    // Note: The formatter itself doesn't expose DtdProcessing directly;
    // use a custom reader or avoid XML for untrusted input.
});

// Better: Use a custom input formatter or avoid XML for untrusted payloads.

A more reliable approach is to sanitize or reject XML containing DOCTYPE declarations before parsing:

[HttpPost]
public IActionResult PostXml([FromBody] string xmlRaw)
{
    if (xmlRaw.Contains("

// Instead of letting WCF auto-deserialize:
public void ProcessMessage(XmlDocument doc)
{
    // Unsafe if doc came from raw input with DTD
}

// Do this:
public void ProcessMessage(Stream inputStream)
{
    var settings = new XmlReaderSettings()
    {
        DtdProcessing = DtdProcessing.Prohibit,
        MaxCharactersFromEntities = 1024
    };
    using (var reader = XmlReader.Create(inputStream, settings))
    {
        var doc = new XmlDocument();
        doc.Load(reader);
        // Now safe
    }
}