解决方案 
  
　　将FSO组件和删除或改名的方式我们不再过多的加以说明了，这一类的解决方法网络上已经有很多文章介绍了。 
  
　　另外还有一种关于ASP的FSO组件漏洞的相应解决方案，即根据用户设置权限。在IIS里，可以设置每个站点的匿名访问所使用的帐号，默认为IUSR_ HostName，这一方法的原理就是针对每一个共享主机用户分别设置一个Windows帐号，如IUSR_HostName1，IUSR_ HostName 2等，然后将每一个用户限制在各自的Web目录下。 
   
  
　　我们仔细的研究一下这种方案，可以发现这个方案无法真正实现安全。因为系统运行ASP时并不是使用的IUSR_ HostName帐号，而是IWAM_ HostName帐号,就象在ASP.NET中使用的用户ASPNET一样。也就是说每个ASP程序所拥有的权限并不是IUSR_ HostName的权限，而是IWAM_HostName用户的权限。这样的方法无法真正的将每个共享主机用户的文件系统访问权限限制在各自的虚拟站点中，每个用户仍然可以访问别人的代码。所以这种方法在ASP.NET中无法真正实现用户之间的安全性。 
  
　　在ASP.NET中相应的运行ASP.NET程序的帐号为ASPNET，和上面所说的ASP中的解决方案类似，我们只能限制此用户不能访问系统目录等其他目录，但是无法防止用户访问其他共享主机用户的程序代码，无法从根本上杜绝这种问题。 
  
　　那么，有没有真正的解决方案了呢？ 
  
　　有！这就是.NET Framework 的新特性――代码访问安全性 
  
　　为了更好的理解这一问题的解决方法,我们需要先介绍一下.NET Framework的安全机制。然后再结合我们的实际问题来讨论解决方案。 
  
　　为了解决安全问题，.NET Framework提供了一种称为代码访问安全性的安全机制。代码访问安全性允许根据代码的来源和代码的标识等属性将代码设置为不同级别的信任代码,同时还详细定义了不同级别的对代码的信任，从而可以详细的对代码设置各自的权限而不是将最大权限赋给所有的代码。使用代码访问安全性，可以减小恶意代码或各种错误的代码带来的严重的系统安全性问题的可能性。您可以设置允许代码执行的一组操作，同样可以设置永远不允许代码执行的一组操作。 
  
　　实现代码访问安全性的基础就是JIT（运行时编译）和IL（中间代码）。所以所有以公共语言运行库为目标的托管代码都会受益于代码访问安全性。非托管代码则无法完全使用代码访问安全性。