如果在 .NET Framework 環境中將代碼分離成程序集，請考慮每段代碼所需的權限級別。您會發現這是一個很容易的過程：把需要較高權限的代碼分離到可賦予其更多權限的單獨的程序集中，同時使其余大部分程序集以較低的權限運行，從而在您的代碼周圍添加更多的防護。 在進行此操作時，不要忘了，由于代碼訪問安全 (CAS) 堆棧的作用，您限制的不僅是自己程序集的權限，也包括您調用的任何程序集的權限。

　　許多人建立了自己的應用程序，使得其產品在測試并提供給客戶后可以插入新的組件。保護這種類型的應用程序非常困難，因為您無法測試所有可能的代碼路徑來發現錯誤和安全漏洞。然而，如果您的應用程序是托管的，則 CLR 提供了一個極好的功能，可以使用它關閉這些可擴展點。通過聲明一個權限對象或一個權限集并調用 PermitOnly 或 Deny，您可以為自己的堆棧添加一個標記，它將阻塞授予您調用的任何代碼的權限。通過在調用某個插件之前進行此操作，您就可以限制該插件所能執行的任務。例如，一個用于計算分期付款的插件不需要任何訪問文件系統的權限。這只是最小權限的另一個例子，由此您可以事先保護自己。請確保記錄下這些限制，并注意，具有較高權限的插件能夠使用 Assert 語句逃避這些限制。

　　8. 注意失敗模式

　　接受它吧。其他人和您一樣憎恨編寫錯誤處理代碼。導致代碼失敗的原因如此眾多，一想到這些就讓人沮喪。大多數程序員，包括我們，更愿意關注正常的執行路徑。那里才是真正完成工作的地方。讓我們盡可能快而無痛地完成這些錯誤處理，然后繼續下一行真正的代碼吧。

　　只可惜，這種情緒并不安全。相反，我們需要更密切地關注代碼中的失敗模式。人們對這些代碼的編寫通常很少深入注意，并且常常沒有經過完全測試。還記得最后一次您完全肯定調試過函數的每一行代碼，包括其中每一個很小的錯誤處理程序是什么時候？

　　未經測試的代碼常會導致安全漏洞。有三件事情可以幫助您減輕這個問題。首先，對那些很小的錯誤處理程序給予和正常代碼同樣的關注。考慮當您的錯誤處理代碼執行時系統的狀態。系統是否處于有效并且安全的狀態中？其次，一旦您編寫了一個函數，請逐步將它徹底調試幾遍，確保測試每一個錯誤處理程序。注意，即使使用這樣的技術，也可能無法發現非常隱秘的計時錯誤。您可能需要給您的函數傳遞錯誤參數，或者以某種方式調整系統的狀態，以使您的錯誤處理程序得以執行。通過花時間單步調試代碼，您可以慢下來并有足夠的時間來查看代碼以及系統運行時的狀態。通過在調試器中仔細單步執行代碼，我們在自己的編程邏輯中發現了許多缺陷。這是一個已得到證明的技術。請使用這一技術。最后，確保您的測試組合能使您的函數進行失敗測試。盡量使測試組合能夠檢驗函數中的每一行代碼。這能幫助您發現規律，特別是當使測試自動化并在每次建立代碼后運行測試時。 關于失敗模式還有一件非常重要的事情需要說明。當您的代碼失敗時要確保系統處于可能的最安全狀態。下面顯示了一些有問題的代碼：


bool accessGranted = true; // 過于樂觀！
try {
// 看看我們能否訪問 c:test.txt
new FileStream(@"c:test.txt",
FileMode.Open,
FileAccess.Read).Close();
}
catch (SecurityException x) {
// 訪問被拒絕
accessGranted = false;
}
catch (...) {
// 發生了其他事情
}

　　盡管我們使用了 CLR，我們仍被允許訪問該文件。在這種情況下，并沒有引發一個 SecurityException。但是，例如，如果文件的自由訪問控制列表 (DACL) 不允許我們訪問呢？這時，會引發另一種類型的異常。但由于代碼第一行的樂觀假設，我們永遠也不會知道這一點。

　　編寫這段代碼的一種更好的方法就是持謹慎態度：

bool accessGranted = false; // 保持謹慎！
try {
// 看看我們能否訪問 c:test.txt
new FileStream(@"c:test.txt",
FileMode.Open,
FileAccess.Read).Close();
// 如果我們還在這里，那么很好！
accessGranted = true;
}
catch (...) {}

　　這樣會更加穩定，因為無論我們如何失敗，總會回到最安全的模式。

　　9. 模擬方式非常容易受到攻擊

　　編寫服務器應用程序時，您常常會發現自己直接或間接使用了 Windows 的一個稱為模擬的很方便的功能。模擬允許進程中的每個線程運行在不同的安全環境中，通常是客戶端的安全環境。例如，當文件系統重定向器通過網絡收到一個文件請求時，它對遠程客戶端進行身份驗證，檢查以確認客戶端的請求沒有違反共享上的 DACL，然后把客戶端的標記附加到處理請求的線程上，從而模擬客戶端。然后此線程便可以使用客戶端的安全環境訪問服務器上的本地文件系統。由于本地文件系統已經是安全的，因此這樣做很方便。它會考慮所請求的訪問類型、文件上的 DACL 和線程上的模擬標記來進行一個訪問檢查。如果訪問檢查失敗，本地文件系統會將其報告給文件系統重定向器，然后重定向器向遠程客戶端發送一個錯誤。毫無疑問，對文件系統重定向器來說這很方便，因為它只是簡單地把請求傳給本地文件系統，讓它去做自己的訪問檢查，就好象客戶端在本地一樣。 這對于文件重定向器這樣簡單的網關而言，一切良好。但模擬常常用在其他更復雜的應用程序中。以一個 Web 應用程序為例。如果您編寫一個經典的非托管 ASP 程序、ISAPI 擴展或 ASP.NET 應用程序，在它的 Web.config 文件中有如下指定

　　＜identity impersonate='true'＞

　　那么您的運行環境將有兩種不同的安全環境：您將具有一個進程標記和一個線程標記，一般來說，線程標記會被用來做訪問檢查（見圖 ）。假設您正在編寫一個在 Web 服務器進程中運行的 ISAPI 應用程序，并假定大多數請求未經身份驗證，則您的線程標記可能是 IUSR_MACHINE，而進程標記卻是 SYSTEM！假設您的代碼能被一個壞家伙通過緩沖區溢出利用。您認為他會只滿足作為 IUSR_MACHINE 運行嗎？當然不會。他的攻擊代碼很可能會調用 RevertToSelf 以刪除模擬標記，從而希望提高他的權限級別。在這種情況下，他會很容易獲得成功。他還可以調用 CreateProcess。它不會從模擬標記復制新進程的標記，而是從進程標記復制，這樣新進程便可以作為 SYSTEM 運行。