.NET 7 中的重大变更：XmlSecureResolver 已过时

.NET 7 中的重大变更：XmlSecureResolver 已过时

你是否曾经在 XML 处理中依赖 XmlSecureResolver 来确保资源解析的安全性？在 .NET 7 中，这个曾经重要的安全组件已经正式被标记为过时（Obsolete）。本文将深入解析这一变更的背景、影响以及迁移方案。

变更概述

在 .NET 7 中，System.Xml.XmlSecureResolver 类型及其 GetEntity 方法被标记为过时，具体表现为：

• 编译时警告：所有对 XmlSecureResolver 的引用都会产生 SYSLIB0047 编译警告
• 运行时异常：XmlSecureResolver.GetEntity 方法无条件抛出 XmlException
• 安全策略变更：从"危险失败"模式转向"安全失败"模式

代码示例：变更前后对比

❌ 过时的用法（.NET 7 之前）

using System.Xml;

// .NET 6 及之前版本：可以正常使用但存在安全隐患
XmlResolver resolver = new XmlSecureResolver(
    resolver: new XmlUrlResolver(),
    securityUrl: "https://www.example.com/");

// 在 .NET 7 中这会抛出 XmlException
object entity = resolver.GetEntity(
    absoluteUri: new Uri("https://www.example.com/some-entity"),
    role: null,
    ofObjectToReturn: null);

✅ 推荐的替代方案（.NET 7+）

using System.Xml;

// 使用新的安全解析器
XmlResolver resolver = XmlResolver.ThrowingResolver;

// 或者使用 XmlUrlResolver（如果确实需要外部资源解析）
// XmlResolver resolver = new XmlUrlResolver();

变更的技术背景

历史行为分析

为了更好地理解这一变更，让我们通过一个表格来对比不同版本的行为差异：

.NET 版本	XmlSecureResolver 行为	安全级别	备注
.NET Framework	构建 CAS 沙箱，违反策略时抛出 SecurityException	高	基于代码访问安全（CAS）
.NET Core 3.1 / .NET 6	无限制地进行外部资源解析	低	CAS 已弃用，无实际安全限制
.NET 7+	无条件抛出 XmlException	高	安全失败模式，防止意外解析

安全架构演进

迁移路径详解

1. 识别受影响代码

使用以下正则表达式搜索项目中的相关代码：

XmlSecureResolver|SYSLIB0047

2. 迁移策略选择

根据不同的使用场景，选择适当的迁移方案：

使用场景	推荐替代方案	注意事项
完全禁止外部资源解析	XmlResolver.ThrowingResolver	最安全的选项
需要有限的外部资源解析	自定义 XmlResolver 实现	需要手动实现安全控制
需要完整的外部资源功能	XmlUrlResolver	了解潜在的安全风险

3. 代码重构示例

场景一：完全禁止外部资源

// 重构前
var secureResolver = new XmlSecureResolver(new XmlUrlResolver(), null);

// 重构后  
var throwingResolver = XmlResolver.ThrowingResolver;

场景二：需要自定义安全策略

// 自定义安全解析器实现
public class CustomSecureResolver : XmlResolver
{
    private readonly XmlResolver _innerResolver;
    
    public CustomSecureResolver(XmlResolver innerResolver)
    {
        _innerResolver = innerResolver;
    }
    
    public override object GetEntity(Uri absoluteUri, string role, Type ofObjectToReturn)
    {
        // 实现自定义的安全检查逻辑
        if (!IsUriAllowed(absoluteUri))
        {
            throw new XmlException($"Access to {absoluteUri} is not allowed");
        }
        
        return _innerResolver.GetEntity(absoluteUri, role, ofObjectToReturn);
    }
    
    private bool IsUriAllowed(Uri uri)
    {
        // 实现你的安全验证逻辑
        return uri.Host.Equals("trusted-domain.com", StringComparison.OrdinalIgnoreCase);
    }
    
    // 其他必要的方法实现...
}

深入理解安全影响

为什么这个变更是必要的？

1. CAS 技术的淘汰：代码访问安全（CAS）在现代 .NET 中已被弃用
2. 错误的安全感：在 .NET Core 中，XmlSecureResolver 实际上没有提供任何安全保护
3. 明确的安全边界：新的行为明确了安全期望，避免了混淆

安全最佳实践

版本兼容性考虑

多目标框架支持

如果你的项目需要支持多个 .NET 版本，可以使用条件编译：

#if NET7_0_OR_GREATER
    XmlResolver resolver = XmlResolver.ThrowingResolver;
#else
    XmlResolver resolver = new XmlSecureResolver(new XmlUrlResolver(), null);
#endif

渐进式迁移策略

1. 第一阶段：处理编译警告，添加 #pragma warning disable 临时抑制
2. 第二阶段：实现替代方案，进行充分测试
3. 第三阶段：移除过时代码，完成迁移

常见问题解答

Q: 这个变更会影响我的现有应用程序吗？

A: 如果你的应用程序在 .NET 7+ 上运行并使用 XmlSecureResolver，将会遇到运行时异常。需要迁移到新的解决方案。

Q: 为什么不能继续保持之前的行为？

A: 之前的行为提供了错误的安全感，实际上在 .NET Core 中没有任何安全限制，这可能导致安全漏洞。

Q: 是否有向后兼容的解决方案？

A: 可以使用多目标框架编译或实现自定义的解析器来保持兼容性。

总结

.NET 7 中 XmlSecureResolver 的过时标记是一个重要的安全改进，它解决了之前版本中存在的安全隐患。虽然这个变更需要开发者进行代码迁移，但它提供了更明确和可靠的安全边界。

关键要点：

• 立即检查项目中是否存在 XmlSecureResolver 的使用
• 迁移到 XmlResolver.ThrowingResolver 或实现自定义安全逻辑
• 理解这一变更背后的安全 rationale（基本原理）
• 为多目标框架项目制定适当的迁移策略

通过采用新的安全模式，你的应用程序将获得更可靠的安全保障，避免潜在的外部资源解析风险。