远程处理的安全性

本主题介绍一项传统技术，保留该技术是为了向后兼容现有的应用程序，不建议对新的开发使用该技术。现在应该使用  Windows Communication Foundation (WCF) 来开发分布式应用程序。

作为一名 .NET 远程处理应用程序开发人员，您必须十分了解 .NET 远程处理以及一般分布式应用程序的安全隐患。如果实现的安全性不高，任何人都可能对远程对象调用方法或者截获来往于远程对象的机密信息。若要避免这种情况发生，必须对客户端（有时也包括服务器）进行身份验证并对二者之间的通信进行加密。

另外还存在一些不太明了的问题。假设有一个远程对象，它定义了一个将委托用作参数的方法。恶意开发人员可以使用委托强制服务器应用程序运行他（她）希望运行的任何代码。当委托包装静态方法时，将不会远程处理对该委托的任何调用，因为代码是在调用该委托的应用程序域中调用的。例如，恶意客户端可能会通过调用远程对象并传递包装静态方法的委托来利用此漏洞。它可以将实现该静态方法的程序集复制到服务器上，当调用委托时，将在服务器上执行该静态方法。若要避免这种情况发生，应始终使用无法被黑客猜到的自定义类型和参数来声明远程对象中使用的委托。另外，切勿允许客户端定义类型并将类型传递给要反序列化的远程对象。

本节介绍根据某些设计决策来增强安全性的各种方法。此处并未包罗所有方案，但这些主题将是一个不错的起点。

代码访问安全性

代码访问安全性是帮助限制代码对受保护的资源和操作的访问权限的一种机制。通常情况下，当代码尝试访问受保护的资源时，将执行堆栈审核，以确保所有堆栈帧都有权访问该资源。而调用远程对象时，则不跨越远程处理边界执行堆栈审核。因此，远程处理基础结构要求必须具有 FullTrust 权限才能在客户端或服务器上执行代码。FullTrust 权限实质上是关闭代码访问安全性。在未经授权的情况下，对远程处理应用程序的任何使用都会出现对 FullTrust 权限的未授权访问。

注意：
有些系统类型扩展了 MarshalByRefObject，但它们在运行时仍会执行安全检查，目的是防止应用程序域之外的任何代码远程调用属于该类型的对象。AppDomain 和 System.Windows.Forms.Form 就是此类系统类型的两个示例。

远程处理应用程序中的安全注意事项

一般而言，在分布式应用程序中必须注意两个方面的安全问题：保护通信信道的安全和防止应用程序受到不正当使用。

保护通信信道的安全涉及两个方面：一是确保将消息加密，二是确保它们在传输过程中不会被修改。防止应用程序受到不正当使用涉及对调用方进行身份验证和授权。对调用方进行身份验证是指验证调用方与其声明的身份是否相符。对调用方进行授权是指，验证调用方是否具有所需的特权来执行某项调用或访问某项受保护的资源。

下面是各个内置信道对安全性的支持情况：

HttpChannel - 仅当远程对象由 Internet 信息服务 (IIS) 承载时才支持身份验证。仅当将 IIS 配置为使用 SSL 时才支持加密。

TcpChannel - 支持身份验证和加密。

IpcChannel - 支持身份验证。

注意：
授权是由代码提供的。内置信道不能为您提供授权，因为它们不知道代码会执行哪些操作，亦不知您对代码施加了什么限制。

警告：
.NET Framework 远程处理在默认情况下不进行身份验证或加密。因此，在与客户端或服务器进行远程交互之前，建议您先执行所有必要的步骤来确认它们的身份。由于 .NET Framework 远程处理应用程序需要 FullTrust 权限才能执行，因此未经授权的客户端一旦获得服务器的访问权限，它就可以像完全受信任的客户端那样执行代码。应始终验证客户端的身份并对通信流加密。

另请参见

参考

RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices

概念

使用 HTTP 信道进行身份验证

其他资源

.NET Framework 远程处理概述