访问级别和修饰符（私有、密封等）是否在 C# 中用于安全目的？答案

【问题标题】：Do the access levels and modifiers (private, sealed, etc) serve a security purpose in C#?访问级别和修饰符（私有、密封等）是否在 C# 中用于安全目的？
【发布时间】：2009-05-21 01:23:54
【问题描述】：

我发现你可以操纵private and internal members using reflection。我还看到它说'sealed' class is more secure that one that isn't。

修饰符“public、protected、internal、private、abstract、sealed、readonly”是否仅仅是关于设计和 API 使用的君子协定，只要您可以访问反射，就可以打破？如果黑客已经在运行调用您的 API 的代码，那么游戏就已经失败了，对吧？

以下是否比任何其他类更安全？

//private class
sealed class User
{
    private string _secret = "shazam";
    public readonly decimal YourSalary;
    public string YourOffice{get;};
    private DoPrivilegedAction()
    {
    }
}

【问题讨论】：

“黑客”可以在没有来自 .Net 和 Java 的元数据的情况下修改您的代码。任何人都记得 DeHacked en.wikipedia.org/wiki/Dehacked 尽你所能希望让它变得尽可能困难。

标签： c# security sealed

【解决方案1】：

首先，回答您的问题：安全系统旨在保护优秀用户免受不良代码；它显然不是为了保护 GOOD CODE 免受不良用户的影响。您的访问限制减轻了部分受信任的恶意代码对您用户的攻击。它们不会减轻来自敌对用户的对您的代码的攻击。如果威胁是恶意用户获取您的代码，那么您就有大问题了。安全系统根本无法减轻这种威胁。

其次，解决前面的一些答案：理解反射和安全之间的完整关系需要仔细关注细节并很好地理解 CAS 系统的细节。先前发布的答案指出，由于反射，安全性和访问之间没有联系，这是误导和错误的。

是的，反射允许您覆盖“可见性”限制（有时）。这并不意味着访问和安全之间没有联系。其联系在于，使用反射覆盖访问限制的权利与CAS系统有着多方面的深度联系。

首先，为了任意，代码必须获得 CAS 系统的私有反射权限。这通常只授予完全受信任的代码，毕竟这些代码已经可以做任何事情。

其次，在新的 .NET 安全模型中，假设程序集 A 被 CAS 系统授予程序集 B 的授权集的超集。在这种情况下，程序集 A 中的代码可以使用反射来观察 B 的内部结构。

第三，当您将动态生成的代码加入其中时，事情变得非常复杂。解释“Skip Visibility”与“Restricted Skip Visibility”的工作原理，以及它们如何在代码在运行时被吐出的情况下改变反射、访问控制和安全系统之间的交互，这将比我花费更多的时间和空间有可用的。如果您需要详细信息，请参阅 Shawn Farkas 的博客。

【讨论】：

如果我理解正确，那么如果一个人在中等信任中运行潜在的恶意代码，那么具有限制性 private/sealed/readonly 的代码确实更安全。
正确。当然，如果恶意代码是完全信任的，那么它就已经结束了，伙计。敌对的完全信任代码可以做任何它想做的坏事。完全信任意味着完全信任！

【解决方案2】：

访问修饰符不是为了安全，而是为了好的设计。类和方法的适当访问级别驱动/实施良好的设计原则。理想情况下，反射应该只在使用它的便利性比违反（如果有的话）最佳设计实践的成本提供更多效用时使用。密封类仅用于防止开发人员扩展您的类并“破坏”它的功能。关于密封类的效用，众说纷纭，但由于我是做 TDD 的，而且很难模拟一个密封类，所以我尽量避免。

如果您想要安全，您需要遵循编码实践，以防止坏人进入和/或保护机密信息不被检查，即使发生入侵也是如此。入侵防御、入侵检测、加密、审计等是您需要使用的一些工具来保护您的应用程序。设置限制性访问修饰符和密封类与应用程序安全几乎没有关系，IMO。

【讨论】：

【解决方案3】：

没有。这些与安全无关。反射打破了一切。

【讨论】：

这是误导。详情见我的回答。
Eric，OP 确实规定，“只要您可以访问 Reflection”。是否存在代码可以访问反射但被阻止访问私有、内部、受保护或受保护的内部成员和类型的情况？
是的，但您几乎肯定不会遇到它们，除非您是编译器编写者，正在编写与 silverlight 一起工作的编译器。有一些晦涩的场景涉及 Silverlight、从表达式树动态生成的代码以及编译器生成的闭包类。我们最终对 silverlight 安全系统进行了一些小改动以解决这些问题，但仍有潜在问题希望在未来的版本中得到解决。

【解决方案4】：

关于反射和安全性的 cmets - 考虑到 mscorlib.dll 中有许多内部类型 + 成员调用本机 Windows 函数，如果恶意应用程序使用反射调用它们，可能会导致不良后果。这不一定是问题，因为不受信任的应用程序通常不会被运行时授予这些权限。这（以及一些声明性安全检查）是 mscorlib.dll 二进制文件如何将其类型暴露给各种受信任和不受信任的代码，但不受信任的代码无法绕过公共 API。

这实际上只是触及了反射 + 安全问题的表面，但希望它足以引导您走上正确的道路。

【讨论】：

【解决方案5】：

我总是尝试将事情锁定到所需的最低访问权限。就像 tvanfosson 所说，这实际上是关于设计而不是安全性。

例如，我将公开一个接口，以及我的内部实现，然后是一个公共工厂类/方法来获取实现。这几乎迫使消费者始终将其键入为接口，而不是实现。

话虽如此，开发人员可以使用反射来实际实例化实现类型的新实例。没有什么能阻止他/她。不过，我可以放心，因为我让违反设计至少有些困难。

【讨论】：