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

Question

中信任托管环境中缺乏反射似乎给许多流行的 Web 应用程序带来了很多问题。

• 为什么使用 Medium Trust 默认禁用ReflectionPermission ？
• 反射在共享托管环境中会带来什么风险？

有关随机参考，请参阅MSDN：如何在 ASP.NET 2.0 中使用中等信任

Answer 1

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

当然，许多程序理所当然地通过更容易受到攻击的向量公开这些数据，但没有理由增加应用程序的攻击面。

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

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

在更难预防的共享托管环境中，尽管这当然不是不可能的。也许值得将这个问题交叉发布到ServerFault，看看那里的好人有什么要说的。

Answer 2

我从来没有发现用户可以使用反射来做任何“坏事”。人们被吓跑了，因为您可以调用标记为私有或受保护的方法，但据我所知，它们都没有带来任何真正的风险。

最有可能的是，它至少在一定程度上是一种销售技巧，可以让您为（半）专用托管服务 :)

Answer 3

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

反射的安全注意事项

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

反射提供了获取有关类型和成员的信息以及访问成员的能力。访问非公共成员可能会产生安全风险。因此，访问非公共成员的代码需要具有适当标志的 ReflectionPermission。

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

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

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

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

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

如果我错了，请纠正我。