解决方案
将FSO组件和删除或改名的方式我们不再过多的加以说明了,这一类的解决方法网络上已经有很多文章介绍了。
我们仔细的研究一下这种方案,可以发现这个方案无法真正实现安全。因为系统运行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(中间代码)。所以所有以公共语言运行库为目标的托管代码都会受益于代码访问安全性。非托管代码则无法完全使用代码访问安全性。
更多内容请看路由安全配置专题、系统安全设置、配置安全的操作系统专题,或进入讨论组讨论。
相关专题
- .NET开发人员犯的6大安全错误 (6次浏览)
- 请跟我来--使用Ext搞个原型 (1次浏览)
- ASP.NET 3.5 Extensions带来什么 (1次浏览)
- 应用WEB标准会使ScrollTop属性失效! (0次浏览)
- Cache用法之缓存页面和缓存数据 (0次浏览)
- 支持正则表达式的UrlMapping (0次浏览)
- 关于ASP.NET 2.0的目录结构变化 (0次浏览)
- WPF中Closing窗体时调用Hide()方法异常 (0次浏览)
- 对象数组根据某属性列的灵活排序 (0次浏览)
- DB2 9和ASP.NET 2.0构建下一代应用程序 (0次浏览)



