Security Briefs...小心完全信任的代码

核心提示： AppDomain 安全策略有屏障作用吗？如果说整个 AppDomain 概念是 ASP.NET 不可缺少的，我对此并不感到惊奇，Security Briefs...小心完全信任的代码(6)，ASP.NET 使用它来在进程中隔离应用程序，如果你不熟悉 AppDomain，用 C++ 编写一

AppDomain 安全策略有屏障作用吗？

如果说整个 AppDomain 概念是 ASP.NET 不可缺少的，我对此并不感到惊奇。ASP.NET 使用它来在进程中隔离应用程序。如果你不熟悉 AppDomain，它类似于进程，只不过是一个轻轻量级的进程。当某个进程与 CLR 交互时，总是具备一个默认的 AppDomain，其中所有的托管类型都被加载。而通过创建多个 AppDomain ，一个进程可以和几个不同的应用程序交互，根本不用担心其中一个 AppDomain 中的类型会破坏该进程中任何别的 AppDomain 的类型。 AppDomain 间共享对象引用需要利用远程机制（remoting）,并且它不会自动发生。如果你我载单独的 AppDomain 中，并且我想接触你的对象，你传递了一个引用给我，从理论上讲，未经许可，不得擅用。

实际上，在某个 AppDomain 中以完全信任方式运行的程序集确实不会被 AppDomain 边界约束。

完全信任程序集不必是类型安全的。最糟糕的是，如果我愿意，我可以仅凭一个指针，就可以搜刮该进程的整个虚拟地址空间，查找感兴趣的数据。

另外一个需要注意的事情是完全信任程序集被允许通过将 SecurityPermission 置为 UnmanagedCode，便可调用本地代码。这使得侵入他人的 AppDomain 易如反掌，假设你我单独运行在某个 ASP.NET 工作者进程中。如果我想将自己的代码注入到你的 AppDomain，如果我被完全信任，这简直太容易了。我只要引用你的 AppDomain，并且我可以使用象 AppDomain.DoCallBack 这样简单的东西便可将攻击代码发送到你的域（domain）中。Figure 2 中的代码示范了一个人为的例子，在这个例子中，我通过骗取受害者的 AppDomain 使攻击者获得一个引用。

为了玩这种游戏，一个 AppDomain 如何盗取另一个 AppDomain 的引用呢？通过调用非托管代码是可以做到的。CLR 提供了与非托管环境交互的 API，用 C++ 编写一个 DLL，然后从托管代码中调用它，你便可以获得该进程中所有 AppDomain 的引用。