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

我知道你可以操纵。我也看到它说了一个

修饰符“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()
    {
    }
}

---

不，这些与安全无关。反射破坏了它们。

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

---

如果您想要安全，您需要遵循编码实践，以防止坏人进入和/或保护机密信息不受检查，即使发生了入侵。入侵预防、入侵检测、加密、审核等是保护应用程序安全所需的一些工具。设置限制性访问修饰符和密封类与应用程序安全性关系不大，IM.O/P > < P>关于反射和安全性的评论——考虑MyScLybDLL中有许多内部类型+成员调用本机Windows函数，如果恶意应用程序使用反射调用它们，则可能导致恶意。这不一定是个问题，因为不受信任的应用程序通常不会被运行时授予这些权限。这（以及一些声明性的安全检查）就是mscorlib.dll二进制文件如何将其类型暴露给所有形式的受信任和不受信任的代码，而不受信任的代码无法绕过公共API

---

这实际上只是反射+安全问题的皮毛，但希望有足够的信息引导您走上正确的道路。

我总是尝试将事情锁定到所需的最小访问权限。就像tvanfosson所说的，设计比安全更重要

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

---

也就是说，开发人员可以使用反射来实际实例化实现类型的新实例。没有什么能阻止他/她。但是，我可以放心，我至少让违反设计变得有些困难。

首先，回答你的问题：安全系统的设计是为了保护好用户免受坏代码的伤害；它显然不是为了保护好代码不受坏用户的影响而设计的。您的访问限制通过部分信任的恶意代码减轻对用户的攻击。它们不会减轻恶意用户对代码的攻击。如果威胁是恶意用户获取你的代码，那么你就有大问题了。安全系统根本无法缓解这种威胁

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

是的，反射允许您覆盖“可见性”限制（有时）。这并不意味着访问和安全性之间没有联系。这种联系是，使用反射覆盖访问限制的权利以多种方式与CAS系统紧密相连

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

其次，在新的.NET安全模型中，假设程序集A被CAS系统授予程序集B的授予集的超集。在这个场景中，允许程序集A中的代码使用反射来观察B的内部结构

---

第三，在混合中加入动态生成的代码时，事情会变得非常复杂。解释“跳过可见性”与“受限跳过可见性”是如何工作的，以及它们如何在代码在运行时被吐出的场景中改变反射、访问控制和安全系统之间的交互，这将占用我更多的时间和空间。如果您需要详细信息，请参阅Shawn Farkas的博客。

黑客可以在没有.Net和Java元数据的情况下修改您的代码。任何人都记得把所有你能做的都拆开，希望尽可能地让它变得困难。这是误导。详见我的答案。埃里克，OP确实规定，“只要你有权思考”。是否存在这样的情况：代码可能可以访问反射，但无法访问私有、内部、受保护或受保护的内部成员和类型？是的，但除非您是编写使用silverlight的编译器的编译器编写者，否则您几乎肯定不会遇到这些成员和类型。有些模糊的场景涉及silverlight、从表达式树动态生成的代码以及编译器生成的闭包类。我们最终对silverlight安全系统做了一些小改动来解决这些问题，但是