对于许多流行的Web应用程序，Medium Trust托管环境中缺乏反射似乎cause a lot of problems。
答案 0 :(得分：6)
反射允许恶意代码检查各种秘密：不是那么多知识产权（尽管也是如此），而是应该是私密且安全的数据，如连接字符串，密码，银行帐户数据等。< / p>
当然，许多程序通过更容易受到攻击的向量来理解这些数据，但是没有理由增加应用程序的攻击面。
编辑从评论中提出一些对话：
真正的风险可能是不受限制的文件系统访问，这就是将反射变成真正的危险。如果一个坏的演员可以将一个程序集（或者被编译成程序集的东西）放到你的虚拟目录中，那么如果他们有反射权限就会遇到麻烦。 （当然，如果发生这种情况，还有其他潜在的问题，但这不应该忽视这个特殊的漏洞。）
在一个难以预防的共享托管环境中，尽管这当然不是不可能的。也许值得将这个问题交叉发布到ServerFault，以了解那些好人可以说的话。
答案 1 :(得分：4)
我从来没有发现用户可以使用反射做的任何'坏'。 人们会因为你能够调用标记为私有或受保护的方法而受到惊吓，但从我所看到的情况来看，它们都不会带来任何真正的风险。
最有可能的是，它至少部分是一种销售技巧，可以帮助您实现（半）专用托管：）
答案 2 :(得分：3)
我在这个主题上发现了以下MSDN文章：
<强> Security Considerations for Reflection
这篇文章回应了Jeff的回答：
反射提供了能力 获取有关类型和的信息 成员，以及访问成员。 访问非公共成员可以 制造安全风险。因此， 访问非公共成员的代码 需要ReflectionPermission 适当的旗帜。
但是，我不认为这种风险可以在客户的托管帐户之间被利用。看来这只会带来个人风险。例如，使用反射我可以在我的托管环境中探索我自己的程序集。但是，其他客户无法使用反射来探索我的程序集。他们只能探索他们的程序集。
这可能会导致涉及多个开发团队的单个Web应用程序出现问题。一个开发团队可以使用反射来探索另一个开发团队的程序集。
但是，这是共享托管环境的罕见情况。大多数共享托管网站都涉及一个非常小的团队，他们可以完全访问所有代码。换句话说，没有秘密。只要程序集对其他共享主机客户是安全的，那么这不是问题。
启用反射不应对大多数共享托管Web应用程序造成任何风险：
<IPermission class="ReflectionPermission" version="1" Flags="RestrictedMemberAccess"/>
如果我错了，请纠正我。