反射会带来什么风险？（中等信任度）

Question

中等信任托管环境中缺乏反思似乎 造成很多问题 适用于许多流行的 Web 应用程序。

• 为什么是 反射权限 默认情况下禁用中等信任？
• 反射在共享托管环境中会带来什么风险？

随机参考，参见 微软软件定义网络：如何在 ASP.NET 2.0 中使用中等信任

Answer 1

反射允许恶意代码检查各种秘密：与其说是知识产权（当然，也是如此），不如说是应该保密且安全的数据，例如连接字符串、密码、银行帐户数据等。

当然，许多程序当然会通过更容易受到破坏的向量来暴露这些数据，但没有理由增加应用程序的攻击面。

编辑以从评论中提取一些对话：

真正的风险可能确实是不受限制的文件系统访问，这才是将反射变成真正危险的原因。如果坏人可以将程序集（或编译成程序集的东西）放入您的虚拟目录中，那么如果他们具有反射权限，您就会遇到麻烦。（当然，如果发生这种情况，还有其他潜在的问题，但这不应该忽视这个特定的漏洞。）

在共享托管环境中，这种情况更难预防，尽管这并非不可能。也许值得将这个问题交叉发布到 服务器故障 看看那里的好心人怎么说。

Answer 2

我从未发现用户使用反射能够做任何“坏”的事情。人们会害怕，因为您可以调用标记为私有或受保护的方法，但从我所见，它们都不会带来任何真正的风险。

最有可能的是，这至少在一定程度上是一种让您花钱购买（半）专用托管的销售技巧:)

Answer 3

我找到了有关此主题的以下 MSDN 文章：

反思的安全考虑

这篇文章呼应了杰夫的回答：

反思提供了获取有关类型和成员以及访问成员的信息的能力。访问非公共成员可能会造成安全风险。因此，访问非公开会员的代码需要使用适当的标志进行反射启用。

但是，我不认为可以在客户的托管帐户之间利用此风险。看来这只会带来个人风险。例如，使用反射，我可以在我的托管环境中探索我自己的程序集。然而，其他客户无法使用反射来探索 我的 组件。他们只能探索 他们的 组件。

这可能会给涉及多个开发团队的单个 Web 应用程序带来问题。一个开发团队可以使用反射来探索另一开发团队的程序集。

然而，对于共享托管环境来说，这种情况很少见。大多数共享托管网站都涉及一个非常小的团队，他们可以完全访问 全部 代码。换句话说，没有秘密。只要程序集对于其他共享托管客户来说是安全的，那么就不是问题。

启用反射不会对大多数共享托管 Web 应用程序造成任何风险：

<IPermission class="ReflectionPermission" version="1" Flags="RestrictedMemberAccess"/>

如果我错了，请纠正我。