解決方案

將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（中間代碼）。所以所有以公共語言運行庫為目標的托管代碼都會受益于代碼訪問安全性。非托管代碼則無法完全使用代碼訪問安全性。