xmlreadersettings 默认允许 dtd 解析，易受 billion laughs 攻击；必须显式设 dtdprocessing.prohibit、xmlresolver = null 才安全。
XmlReaderSettings 默认不防 Billion Laughs，必须显式禁用 DTD 和外部实体
默认情况下，XmlReader.Create() 使用的 XmlReaderSettings 允许 DTD 解析（DtdProcessing 默认为 Parse），这正是 Billion Laughs 攻击能生效的前提。攻击者上传含递归实体定义的恶意 XML，如 ，会触发指数级内存/ CPU 消耗。
关键操作是：在创建 XmlReader 前，必须手动配置 XmlReaderSettings，关闭 DTD 处理和外部实体加载：
var settings = new XmlReaderSettings
{
DtdProcessing = DtdProcessing.Prohibit,
XmlResolver = null,
ValidationType = ValidationType.None
};
注意：DtdProcessing.Prohibit 是硬性开关，比 Ignore 更安全；XmlResolver = null 防止解析外部实体（如 SYSTEM "http://evil.com/xxe.dtd"）；ValidationType.None 可省略，但显式声明更清晰。
ASP.NET Core 中处理文件上传时的 XmlReaderSettings 配置时机
在 Controller 的 IFormFile 处理流程中，不能直接对原始流调用 XmlReader.Create(stream) 而不传入 XmlReaderSettings —— 这等同于使用不安全的默认设置。
正确做法是在读取前立即构建带防护的 XmlReader：
- 用
file.OpenReadStream()获取流后，立刻传入已配置好的XmlReaderSettings - 避免先将整个文件读入
MemoryStream再解析，否则可能在构造流时就已触发解析（取决于封装逻辑） - 若使用
XmlSerializer，它底层也依赖XmlReader，需通过XmlSerializer.Deserialize(XmlReader)重载传入受控 reader
示例片段：
using var reader = XmlReader.Create(file.OpenReadStream(), settings); var doc = XDocument.Load(reader); // 安全
为什么 XmlSecureResolver 或自定义 XmlResolver 不够用
有人尝试用 XmlSecureResolver 或继承 XmlResolver 并返回 null 来拦截外部请求，但这无法阻止 Billion Laughs —— 因为该攻击完全在 DTD 内部定义，不发起任何外部 HTTP 请求。
真正有效的防线只有两个：
-
DtdProcessing = DtdProcessing.Prohibit：直接拒绝解析任何 DTD 块（包括内部子集） - 不启用
Prohibit时，即使XmlResolver = null，DTD 中的嵌套实体仍会被展开（.NET Framework 4.6+ 和 .NET Core 2.1+ 行为一致）
验证方式：上传含 ]> 的 XML，若未抛出 XmlException 且 y 被展开，则说明 DtdProcessing 未设为 Prohibit。
.NET 5+ 中 XmlReader.Create 的隐式设置陷阱
.NET 5 引入了更严格的默认行为，但仅限于某些重载 —— 比如 XmlReader.Create(string)（文件路径）默认禁用 DTD，而 XmlReader.Create(Stream) 依然沿用老规则（DtdProcessing.Parse）。
这意味着：同一份代码，在读文件 vs 读上传流时，安全性可能不一致。最稳妥的方式始终是显式传入 XmlReaderSettings，而不是依赖运行时版本或重载差异。
容易被忽略的一点：如果项目同时引用了 System.Xml.XmlDocument 和 System.Xml.Xsl，某些 XSLT 处理路径可能绕过你配置的 XmlReaderSettings，此时需检查 XslCompiledTransform.Load() 是否传入了安全的 XmlReader。
