圖 ：檢查

　　那么怎樣解決這個小問題呢？除了首先確保不出現任何緩沖區溢出外，還要記住最小授權原則。如果您的代碼不需要具有 SYSTEM 這樣大的權限，則不要將 Web 應用程序配置為在 Web 服務器進程中運行。如果只是將 Web 應用程序配置為在中等或較高的隔離環境中運行，您的進程標記將會是 IWAM_MACHINE。您實際上沒有任何權限，因而這種攻擊幾乎不會生效。注意，在 IIS 6.0（即將成為 Windows .NET Server 的一個組件）中，默認情況下用戶編寫的代碼不會作為 SYSTEM 運行。基于這樣的認識，即開發人員確實會犯錯誤，Web 服務器就減少賦予代碼的權限而提供的任何幫助都是有益的，以免萬一代碼中存在安全問題。

　　下面是另外一個 COM 程序員可能遇到的隱患。COM 有一個不好的傾向就是敷衍線程。如果您調用一個進程內 COM 服務器，而其線程模型與調用線程的模型不匹配，則 COM 會在另一個線程上執行調用。COM 不會傳播調用者線程上的模擬標記，這樣結果就是調用會在進程的安全環境中執行，而不是在調用線程的安全環境中。多么令人吃驚！

　　下面是另一個由模擬帶來的隱患的情況。假設您的服務器接受通過命名管道、DCOM 或 RPC 發送的請求。您對客戶端進行身份驗證并模擬它們，通過模擬以它們的名義打開內核對象。而您又忘了在客戶端斷開連接時關閉其中的一個對象（例如一個文件）。當下一個客戶端進入時，您又對其進行身份驗證和模擬，猜猜會發生什么？您仍然可以訪問上一個客戶端“遺漏”的文件，即使新的客戶端并沒有獲得訪問該文件的權限。出于運行性能的原因，內核僅在第一次打開對象時對其執行訪問檢查。即使您后來因為模擬其他用戶而更改了安全環境，您還是可以訪問此文件。 以上提及的這些情況都是為了提醒一點，即模擬為服務器開發人員提供了方便，但這種方便卻具有很大隱患。在您采用一個模擬標記運行程序時，務必要對自己的代碼多加注意。

　　10. 編寫非管理員用戶可以實際使用的應用程序

　　這確實是最小授權原則的必然結果。如果程序員繼續開發這樣的代碼，使得必須是管理員身份的用戶才能在 Windows 上正常運行，我們就不能期望提高系統的安全性。Windows 有一套非常穩定的安全功能，但是如果用戶必須具有管理員身份才能進行操作，他們就不能很好地利用這些功能。

　　您怎樣進行改進呢？首先，自己先嘗試一下，不以管理員身份運行。您很快就會知道使用沒有考慮安全設計的程序的痛苦。有一天，我 (Keith) 安裝一個由手持設備制造商提供的軟件，該軟件用于在我的臺式機和手持設備之間同步數據。與往常一樣，我退出了普通的用戶帳戶，然后使用內置的管理員帳戶再次登錄，安裝了軟件，然后再次登錄到普通帳戶，并且試圖運行軟件。結果該應用程序跳出一個對話框，說不能訪問某個所需的數據文件，接著便給出一個訪問沖突信息。朋友們，這就是某個主流手持設備廠商的軟件產品。對這種錯誤還有什么借口嗎？

　　在運行了來自 http://sysinternals.com（英文）的 FILEMON 之后，我很快發現該應用程序試圖打開一個數據文件以進行寫入訪問，而該文件與應用程序的可執行文件安裝在同一目錄中。當應用程序如預想的那樣安裝在 Program Files 目錄中時，他們絕不能試圖向該目錄寫入數據。Program Files 具有這樣一個限制訪問控制策略是有原因的。我們不希望用戶寫入這些目錄，因為這樣會很容易讓一個用戶留下特洛伊木馬程序，而讓另一個用戶去執行。實際上，這個約定是 Windos XP 的基本標志性要求之一。

　　我們聽到太多的程序員給出借口說他們為什么在開發代碼時選擇作為管理員身份運行。如果我們繼續忽略這一問題，只會讓事情更糟。朋友們，編輯一個文本文件并不需要管理員權限。編輯或調試一個程序也不需要管理員權限。在您需要管理員權限時，請使用操作系統的 RunAs 功能來運行緎。

　　我們聽到太多的程序員給出借口說他們為什么在開發代碼時選擇作為管理員身份運行。如果我們繼續忽略這一問題，只會讓事情更糟。朋友們，編輯一個文本文件并不需要管理員權限。編輯或調試一個程序也不需要管理員權限。在您需要管理員權限時，請使用操作系統的 RunAs 功能來運行具有較高權限的單獨的程序。如果您是在編寫給開發人員使用的工具，那么您將對這個群體負有額外的責任。我們需要停止這種編寫只有以管理員身份才能運行的代碼的惡性循環，要達到這一目標，我們必須從根本上發生改變。