Xml Bomb in Aspnet (Csharp)

An XML bomb (also known as a billion laughs attack) leverages nested entity expansion in XML parsers to consume excessive memory and CPU. In an ASP.NET context, this becomes a risk when the application processes untrusted XML input using .NET's built-in XML deserializers or XmlDocument/XDocument without restricting entity expansion. In C#, common patterns such as XmlSerializer.Deserialize, XDocument.Parse, or DataSet.ReadXml can be triggered with a malicious payload that defines deeply nested or repeated entities. When the parser resolves these entities, the recursion and memory growth can spike CPU and memory, leading to denial of service.

For example, an attacker can send an XML body like the following to an endpoint that reads XML in C#:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE lolz [ <!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<root><data>&lol4;</data></root>

If the ASP.NET service uses XmlDocument with default settings, the parser expands these entities recursively, and the C# runtime allocates large amounts of memory for the expanded tree. Because the scan is black-box, middleBrick will flag this as an Input Validation and Unsafe Consumption finding, noting that unauthenticated XML endpoints are susceptible to resource exhaustion. The risk is higher when XML deserialization is combined with permissive schemas or when DTD processing is enabled, which allows external entity references by default in certain .NET configurations.

Additionally, ASP.NET endpoints that accept XML through XDocument.Parse can still be impacted if the parser is not configured to prohibit external entities and if the XML includes DOCTYPE declarations. The framework’s XML readers may not mitigate entity expansion by default, so an attacker can craft payloads that trigger exponential entity expansion. middleBrick’s checks for Data Exposure and Input Validation will highlight whether the endpoint leaks sensitive data or crashes under such payloads, and the LLM/AI Security module verifies whether error messages or verbose responses aid an attacker in refining the bomb.

To secure XML processing in ASP.NET written in C#, you must configure XML readers to prohibit DTD and external entity expansion. Use XmlReaderSettings with ProhibitDtd and XmlResolver set to null, and prefer XDocument with LoadOptions that disable entity processing. Avoid XmlDocument for untrusted data, or if unavoidable, secure it with the same settings. Below are concrete code examples for safer deserialization in ASP.NET.

Example 1: Secure XDocument parsing

Use LoadOptions to disable DTD processing and external references:

using System.Xml.Linq;
using System.Xml.XmlDocument;

var settings = new LoadOptions(
    LoadOptions.SetLineInfo |
    LoadOptions.DisableStreaming
);
// Note: XDocument does not process DTD by default in many configurations,
// but to be explicit about forbidding external entities, avoid passing a reader with DTD enabled.
string safeXml = @"<root><data>example</data></root>";
using var stringReader = new StringReader(safeXml);
using var xmlReader = XmlReader.Create(stringReader, new XmlReaderSettings {
    ProhibitDtd = true,
    XmlResolver = null
});
XDocument doc = XDocument.Load(xmlReader, LoadOptions.None);

Example 2: Secure XmlSerializer with restricted settings

While XmlSerializer does not directly expose DTD settings, ensure the XML is pre-processed or use XmlReader with secure settings before deserialization:

using System.IO;
using System.Xml.Serialization;
using System.Xml;

public class MyData {
    public string Value { get; set; }
}

string xmlInput = @"<?xml version=\"1.0\" encoding=\"utf-8\"?><MyData><Value>test</Value></MyData>";
var settings = new XmlReaderSettings {
    ProhibitDtd = true,
    XmlResolver = null
};
using var reader = XmlReader.Create(new StringReader(xmlInput), settings);
var serializer = new XmlSerializer(typeof(MyData));
var result = (MyData)serializer.Deserialize(reader);

Example 3: Avoid DataSet.ReadXml with untrusted input

DataSet.ReadXml can be risky; if you must use it, sanitize or restrict DTD processing at the reader level:

using System.Data;
using System.Xml;

var dataSet = new DataSet();
var secureSettings = new XmlReaderSettings {
    ProhibitDtd = true,
    XmlResolver = null
};
using var reader = XmlReader.Create(new StringReader(safeXml), secureSettings);
dataSet.ReadXml(reader);

middleBrick’s scans will validate whether these mitigations are effective by testing endpoints with XML bombs and checking for error handling that does not expose stack traces or sensitive data. The findings will include remediation guidance mapped to frameworks such as OWASP API Top 10 and PCI-DSS, helping you prioritize fixes.