智能客戶(hù)端體系結構與設計指南
David Hill, Brenton Webster, Edward A. Jezierski, Srinath Vasireddy and Mohammad Al-Sabt, Microsoft Corporation; Blaine Wastell, Ascentium Corporation; Jonathan Rasmusson and Paul Gale, ThoughtWorks; and Paul Slater, Wadeware LLC
相關(guān)鏈接
Microsoft? patterns & practices 庫
http://www.microsoft.com/resources/practices/default.mspx.NET 的應用程序體系結構：設計應用程序和服務(wù)
http://msdn.microsoft.com/library/en-us/dnbda/html/distapp.asp摘要：本章介紹智能客戶(hù)端的安全性問(wèn)題。智能客戶(hù)端將邏輯和數據分布到客戶(hù)端計算機；因此需要考慮的安全性和與瘦客戶(hù)端應用程序相關(guān)的安全性是不同的，后者的數據和邏輯更多地被限制到服務(wù)器。本章討論智能客戶(hù)端應用程序中的數據安全性、身份驗證、授權以及代碼訪(fǎng)問(wèn)角色的安全性。
智能客戶(hù)端是分布式應用程序，通?？缭蕉喾N不同的產(chǎn)品和技術(shù)。管理這些應用程序中的安全性是一件極具挑戰性的事情。在服務(wù)器端，需要采用一種方法來(lái)保護網(wǎng)絡(luò )、服務(wù)器本身及其應用程序。在客戶(hù)端，應集中于利用平臺（其中包括操作系統和 Microsoft? .NET Framework）的安全特性、客戶(hù)端代碼可以執行的特權操作（代碼訪(fǎng)問(wèn)安全）以及與服務(wù)器平臺（域）和服務(wù)器應用程序的交互。
有效的安全性取決于深層防御方法。在保護智能客戶(hù)端時(shí)，考慮安全性的各個(gè)方面非常重要，其中包括以下幾個(gè)方面：
?
身份驗證。這唯一地標識了客戶(hù)端應用程序的用戶(hù)，從而只有經(jīng)過(guò)認可的用戶(hù)才能訪(fǎng)問(wèn)應用程序的全部或部分。
?
授權。這確定唯一標識的用戶(hù)可以執行的操作。這些操作可以是任務(wù)，也可以是對授予經(jīng)過(guò)身份驗證的用戶(hù)訪(fǎng)問(wèn)權限的資源進(jìn)行的操作。
?
數據驗證。這確保只有適當的和有效的數據才能被應用程序接受。如果允許任何用戶(hù)輸入而不首先驗證數據，則攻擊者就可以通過(guò)插入惡意的輸入來(lái)危及應用程序的安全。
?
保護敏感數據。這意味著(zhù)確保應用程序存儲和傳輸的敏感數據（例如密碼或機密的商業(yè)數據）是安全的。對敏感數據進(jìn)行加密可以確保數據不可能以明文形式獲得；取決于算法的選擇，這還可以確保信息不會(huì )被篡改，從而維護其完整性。
?
審核和日志記錄。這包括保存對事件和用戶(hù)操作的記錄。應該考慮將關(guān)鍵的用戶(hù)操作或活動(dòng)記錄在服務(wù)器上，或者安全地記錄在客戶(hù)端上，因為客戶(hù)端計算機上的日志可能被篡改或清除。
?
異常管理。這確保應用程序適當地處理異常和失敗，并且返回用戶(hù)友好的非敏感信息。異常詳細信息可以記錄到事件日志或應用程序日志中。
?
更改和配置管理。這確保跟蹤 IT 環(huán)境的配置以及對其進(jìn)行的任何更改。通過(guò)這樣做，可以查看是否出現任何未經(jīng)授權的更改，并且確定任何經(jīng)授權的更改所涉及的安全性含義。
本章詳細描述了在設計智能客戶(hù)端應用程序時(shí)將會(huì )面臨的一些關(guān)鍵安全性問(wèn)題，具體來(lái)說(shuō)，重點(diǎn)介紹了身份驗證、授權、數據驗證和保護敏感數據。同時(shí)，本章還介紹了代碼訪(fǎng)問(wèn)安全，它是 .NET Framework 中的一項關(guān)鍵技術(shù)，用于管理代碼級而非用戶(hù)級安全性。
在檢驗智能客戶(hù)端安全性時(shí)還需要考慮的另一個(gè)重要方面是如何部署智能客戶(hù)端。有關(guān)影響部署的安全性問(wèn)題的詳細信息，請參閱
第 7 章：智能客戶(hù)端的部署與更新。
注在應用程序中使用的任何代碼都應該使用 FxCop 進(jìn)行分析。通過(guò)這個(gè)工具，可以檢查托管代碼程序集是否符合 .NET Framework 設計指導原則，其中包括符合基本級別的安全性?？梢詮?GotDotNet 站點(diǎn)
http://www.gotdotnet.com/team/fxcop/ 下載 FxCop。
身份驗證
身份驗證是通過(guò)檢驗他的或她的憑據來(lái)唯一標識用戶(hù)的過(guò)程。當用戶(hù)試圖運行或安裝應用程序時(shí)，或者當應用程序建立到遠程服務(wù)的連接或訪(fǎng)問(wèn)本地保存的數據時(shí)，都可能需要用戶(hù)身份驗證。
這一節分析智能客戶(hù)端常見(jiàn)的一些身份驗證方案，介紹對網(wǎng)絡(luò )調用進(jìn)行身份驗證的幾種不同方式，并討論如何收集用戶(hù)憑據和在脫機時(shí)檢驗這些憑據。
智能客戶(hù)端身份驗證方案
取決于智能客戶(hù)端應用程序的樣式和功能，在用戶(hù)與應用程序交互的過(guò)程中，可能需要在一個(gè)或多個(gè)階段對用戶(hù)進(jìn)行身份驗證。對用戶(hù)進(jìn)行身份驗證可供選擇的階段有四個(gè)：
?
在應用程序安裝時(shí)
?
在應用程序運行時(shí)
?
在用戶(hù)訪(fǎng)問(wèn)本地保存的敏感數據時(shí)
?
在用戶(hù)通過(guò)網(wǎng)絡(luò )訪(fǎng)問(wèn)外部服務(wù)時(shí)
經(jīng)過(guò)身份驗證的安裝
如果應用程序是集中部署的（例如，使用無(wú)接觸部署），則可能需要保護 Web 服務(wù)器上的應用程序，以便只有經(jīng)過(guò)授權的用戶(hù)才能安裝它們。這些用戶(hù)必須首先經(jīng)過(guò) Web 服務(wù)器的身份驗證，Web 服務(wù)器查看他們是否被授權訪(fǎng)問(wèn)該應用程序和將其下載到他們的客戶(hù)端計算機上。
保護對無(wú)接觸部署的智能客戶(hù)端應用程序的訪(fǎng)問(wèn)與保護任何其他位于 Web 服務(wù)器的構件（例如 Web 頁(yè)面）相似。Microsoft Internet Information Services (IIS) 提供了許多身份驗證機制，例如集成 Windows、摘要或基本身份驗證。
注如果使用無(wú)接觸部署并且應用程序使用配置文件來(lái)存儲它的配置設置，則不適合使用摘要和基本身份驗證，因為 .NET Framework 不能使用這些機制自動(dòng)下載配置文件。
在選擇適當的身份驗證機制并且 IIS 可以根據他的或她的憑據標識用戶(hù)之后，就可以通過(guò)設置應用程序和程序集文件上的文件權限來(lái)保護應用程序及其依賴(lài)程序集。為了簡(jiǎn)化對大量用戶(hù)的管理，可以考慮提供對 Microsoft Windows 組（例如 SmartClientAppUsers）的訪(fǎng)問(wèn)，并將各個(gè)用戶(hù)放在這個(gè)組中。
所有需要進(jìn)行身份驗證的用戶(hù)都必須具有服務(wù)器上的 Windows 標識，這樣 IIS 就可以保護對應用程序及其程序集的訪(fǎng)問(wèn)，但是他們未必需要使用這一標識登錄到他們的客戶(hù)端計算機上。如果用戶(hù)的登錄帳戶(hù)不為服務(wù)器端所知，則當他或她單擊指向應用程序的可執行文件的鏈接時(shí)，系統就會(huì )提示用戶(hù)輸入用戶(hù)名和密碼。
如果使用集成 Windows 身份驗證，則系統就會(huì )自動(dòng)使用已登錄用戶(hù)的憑據來(lái)嘗試獲取對應用程序的訪(fǎng)問(wèn)權限。當用戶(hù)通過(guò)為客戶(hù)端和服務(wù)器所共有的標識登錄時(shí)，就可以進(jìn)行無(wú)縫且安全的訪(fǎng)問(wèn)。
經(jīng)過(guò)身份驗證的應用程序訪(fǎng)問(wèn)
對安裝應用程序的用戶(hù)進(jìn)行身份驗證可以確保，只有經(jīng)過(guò)身份驗證和授權的用戶(hù)才能從中心位置運行應用程序。然而，因為應用程序及其依賴(lài)構件可能緩存在客戶(hù)端計算機上，所以不能在應用程序每次運行時(shí)都依賴(lài)于這一機制來(lái)對用戶(hù)進(jìn)行身份驗證。在這種情況下，或者當用戶(hù)有意在本地部署應用程序時(shí)，就需要仔細考慮如何通過(guò)應用程序對用戶(hù)進(jìn)行身份驗證?？赡苄枰谟脩?hù)每次運行應用程序時(shí)就對他們進(jìn)行身份驗證，特別是如果應用程序提供敏感功能，或者需要能夠撤消用戶(hù)在任何時(shí)候運行應用程序的授權。
在用戶(hù)使用為客戶(hù)端和服務(wù)器所共有的標識登錄到客戶(hù)端計算機的情況下，可以依賴(lài)用戶(hù)能夠登錄客戶(hù)端計算機的事實(shí)，并以此作為對運行應用程序的充分身份驗證。通過(guò)這種方法，可以使用 Microsoft Windows 操作系統來(lái)提供用戶(hù)身份驗證，從而使得不必需要用代碼實(shí)現用戶(hù)身份驗證。另外，因為 Windows 可以在脫機時(shí)緩存用戶(hù)憑據，所以您不需要自己緩存它們。
對于您對用戶(hù)訪(fǎng)問(wèn)沒(méi)有任何控制的客戶(hù)端計算機（例如您的組織的 intranet 外的客戶(hù)端計算機），您可能需要采用一種自定義身份驗證機制來(lái)收集用戶(hù)憑據，并且根據遠程安全性授權對他們進(jìn)行身份驗證。如果應用程序能夠脫機操作，您就需要在客戶(hù)端緩存有效的憑據，這樣，當他或她啟動(dòng)應用程序時(shí)，您就可以根據它們重新對用戶(hù)進(jìn)行身份驗證。您應該定期強制執行聯(lián)機重新身份驗證，這樣就可以防止對這樣的應用程序的無(wú)限制使用。
經(jīng)過(guò)身份驗證的本地數據訪(fǎng)問(wèn)
智能客戶(hù)端應用程序常常緩存從遠程服務(wù)獲得的數據（例如，為了提高響應速度或者為了支持脫機功能）。如果數據是敏感的，則可能需要在授予用戶(hù)訪(fǎng)問(wèn)數據的權限之前對其進(jìn)行身份驗證。在這種情況下，可以選擇允許未經(jīng)身份驗證的用戶(hù)運行應用程序，但是需要在授予用戶(hù)訪(fǎng)問(wèn)敏感數據的權限之前對其進(jìn)行充分的身份驗證和授權。
注確保只有授權用戶(hù)訪(fǎng)問(wèn)的數據才能在本地緩存非常重要。如果數據是敏感的，則還需要確保采取足夠的措施來(lái)保證數據的安全。詳細信息請參閱本章后面的“處理敏感數據”。本地保存的數據應該保存在安全的位置并進(jìn)行加密。不管如何對用戶(hù)進(jìn)行身份驗證，通常都需要以某種方式使用他們的憑據來(lái)訪(fǎng)問(wèn)和解密數據。
您可能能夠使用用于登錄到客戶(hù)端計算機的默認憑據，也可能需要獲得自定義憑據來(lái)根據遠程安全性授權對用戶(hù)進(jìn)行身份驗證。對于在 intranet 環(huán)境中運行的應用程序，前一種方式最為合適，而對于在 Internet 或外部網(wǎng)環(huán)境中運行的應用程序，由于用戶(hù)通常不在與他們訪(fǎng)問(wèn)的遠程服務(wù)相同的域中，所以后一種方式比較合適。使用集成 Windows 身份驗證的一個(gè)好處是，操作系統可以對用戶(hù)進(jìn)行身份驗證，保護應用程序和本地數據，并且可以在用戶(hù)脫機時(shí)緩存用戶(hù)憑據。
有關(guān)在本地緩存敏感數據的詳細信息，請參閱本章后面的“處理敏感數據”。
經(jīng)過(guò)身份驗證的網(wǎng)絡(luò )訪(fǎng)問(wèn)
您可能會(huì )選擇支持對應用程序的匿名訪(fǎng)問(wèn)并允許任何用戶(hù)下載和運行它。然而，在應用程序運行在客戶(hù)端之后，它通常需要通過(guò)網(wǎng)絡(luò )訪(fǎng)問(wèn)遠程服務(wù)（例如 Web 服務(wù)）以獲得數據和服務(wù)。
通常需要保護對網(wǎng)絡(luò )數據和服務(wù)的訪(fǎng)問(wèn)，以防止未經(jīng)授權的訪(fǎng)問(wèn)。保護遠程服務(wù)訪(fǎng)問(wèn)的方式可能有許多種，但通常需要將用戶(hù)憑據傳送到遠程服務(wù)，以便它可以執行用戶(hù)身份驗證。
當用戶(hù)通過(guò)網(wǎng)絡(luò )訪(fǎng)問(wèn)遠程服務(wù)時(shí)對他們進(jìn)行身份驗證是一項非常重要的內容。本章后面的“網(wǎng)絡(luò )訪(fǎng)問(wèn)身份驗證類(lèi)型”比較完整地描述了確保對網(wǎng)絡(luò )服務(wù)調用進(jìn)行身份驗證的一些選擇。
選擇正確的身份驗證模型
前一節描述了您可能選擇用來(lái)對用戶(hù)進(jìn)行身份驗證的四個(gè)階段。您可能選擇在一個(gè)或多個(gè)階段對用戶(hù)進(jìn)行身份驗證，這取決于您的應用程序及其功能的性質(zhì)。選擇正確的階段是非常重要的，它既可以幫助確保應用程序和數據的安全，又可以將對應用程序的使用的任何影響降低到最低限度。
如果您的應用程序是集中部署的（例如，如果使用無(wú)接觸部署進(jìn)行部署，或者部署到文件共享），則您可能選擇將訪(fǎng)問(wèn)僅限于經(jīng)過(guò)授權的用戶(hù)。如果您想讓您的應用程序對任何想要使用它的人都可用，則不需要在安裝應用程序時(shí)對用戶(hù)進(jìn)行身份驗證。
客戶(hù)端計算機通常在物理上并不安全，甚至可能能夠進(jìn)行公開(kāi)訪(fǎng)問(wèn)。如果是這種情況，并且應用程序提供敏感功能，則往往需要在應用程序運行時(shí)對用戶(hù)進(jìn)行身份驗證。如果應用程序提供的是匿名用戶(hù)可用的常規功能，則不需要在這一階段對用戶(hù)進(jìn)行身份驗證。然而，您可能會(huì )選擇給匿名用戶(hù)提供應用程序的部分功能，但是需要在允許他們訪(fǎng)問(wèn)更多受限功能之前對其進(jìn)行身份驗證。
保護對本地保存的敏感數據的訪(fǎng)問(wèn)非常重要。如果應用程序部署在物理上不安全或者可以公開(kāi)訪(fǎng)問(wèn)的設備上，則應該對敏感數據進(jìn)行保護，并且只有經(jīng)過(guò)身份驗證和授權的用戶(hù)才能訪(fǎng)問(wèn)它們。應用程序可以給匿名用戶(hù)提供常規功能，但是在用戶(hù)試圖訪(fǎng)問(wèn)敏感數據時(shí)需要對他們進(jìn)行身份驗證。
在應用程序脫機運行時(shí)，使用集成 Windows 身份驗證也有好處。在這種情況下，Windows 緩存用戶(hù)憑據，以便當用戶(hù)登錄到脫機客戶(hù)端計算機時(shí)對他（她）進(jìn)行身份驗證。如果您需要在應用程序運行或訪(fǎng)問(wèn)本地保存的敏感數據時(shí)對用戶(hù)進(jìn)行身份驗證，則這一行為使得您的客戶(hù)端不需要對用戶(hù)進(jìn)行身份驗證。
網(wǎng)絡(luò )訪(fǎng)問(wèn)身份驗證類(lèi)型
有許多不同的技術(shù)可以用來(lái)在用戶(hù)訪(fǎng)問(wèn)遠程服務(wù)時(shí)對其進(jìn)行身份驗證，其中包括：
?
集成 Windows 身份驗證。
?
HTTP 基本身份驗證。
?
HTTP 摘要身份驗證。
?
基于證書(shū)的身份驗證。
?
基于 Web Services Enhancements (WSE) 的身份驗證。
?
自定義身份驗證。
集成 Windows 身份驗證
對于集成 Windows 身份驗證，用戶(hù)是通過(guò)使用有效的 Windows 帳戶(hù)登錄到他的或她的計算機來(lái)進(jìn)行身份驗證的。憑據可以是本地帳戶(hù)（對于計算機來(lái)說(shuō)，帳戶(hù)是本地的）或域帳戶(hù)（Windows 域的有效成員）。在用戶(hù)的整個(gè)會(huì )話(huà)期間，應用程序都可以透明地使用登錄時(shí)所建立的標識來(lái)訪(fǎng)問(wèn)資源。這意味著(zhù)應用程序可以用一種安全的方式提供對網(wǎng)絡(luò )資源（例如 Web 服務(wù)）的無(wú)縫訪(fǎng)問(wèn)，而不必提示用戶(hù)輸入其他憑據或重復輸入憑據。
注只有當網(wǎng)絡(luò )資源也使用集成 Windows 身份驗證時(shí)，對網(wǎng)絡(luò )資源的訪(fǎng)問(wèn)才是無(wú)縫的。
集成 Windows 身份驗證使用以下兩種身份驗證協(xié)議中的一種：Kerberos 或 NTLM。這兩種技術(shù)都不通過(guò)網(wǎng)絡(luò )傳送用戶(hù)名和密碼組合來(lái)對用戶(hù)進(jìn)行身份驗證或驗證。因此，您的應用程序或基礎結構在傳輸的過(guò)程中不必提供附加的安全性來(lái)管理憑據。
依賴(lài)于 Windows 安全性的客戶(hù)端應用程序使用名為 WindowsIdentity 的 IIdentity 接口的實(shí)現。
注.NET Framework 也提供緊密相關(guān)的 IPrincipal 接口。有關(guān) IIdentity 和 IPrincipal 接口的更多詳細信息，請參閱本章后面的“授權”。
使用集成 Windows 身份驗證的 Web 服務(wù)
對于為集成 Windows 身份驗證配置的 Web 服務(wù)，客戶(hù)端應用程序可以在調用 Web 服務(wù)之前提供當前登錄的用戶(hù)的憑據來(lái)進(jìn)行身份驗證。當從 Microsoft Visual Studio .NET 開(kāi)發(fā)系統將引用添加到應用程序中的 Web 服務(wù)時(shí)，系統會(huì )自動(dòng)生成一個(gè)代理類(lèi)并將其添加到項目中，以便通過(guò)編程方式訪(fǎng)問(wèn) Web 服務(wù)。下面的代碼演示了如何設置當前登錄的用戶(hù)的用戶(hù)憑據。
MyService service = new MyService(); // A proxy for a web service. service.Credentials = CredentialCache.DefaultCredentials; service.SomeServiceMethod(); // Call the web service.
在本例中，DefaultCredentials 使用應用程序正在其中運行的安全性上下文，它通常是運行應用程序的用戶(hù)的 Windows 憑據（用戶(hù)名、密碼和域）。
HTTP 基本身份驗證
HTTP 基本身份驗證是由 IIS 提供的。在進(jìn)行基本身份驗證時(shí)，IIS 會(huì )提示用戶(hù)輸入一個(gè)有效的 Windows 帳戶(hù)和密碼。這一組合是作為經(jīng)過(guò)編碼的明文從客戶(hù)端傳送到服務(wù)器，并用于在 Web 服務(wù)器上對用戶(hù)進(jìn)行身份驗證。
注為了保護基本身份驗證，您需要保護客戶(hù)端和服務(wù)器之間的通信信道（例如，通過(guò)啟用服務(wù)器上的安全套接字層 [SSL]），以確保用戶(hù)名/密碼組合被加密并且在傳輸時(shí)不會(huì )被篡改或截獲。同時(shí)，您還需要保護位于服務(wù)器上的密碼。然而，SSL 只能保護兩個(gè)已定義的終結點(diǎn)之間的通信。如果您需要保護兩個(gè)以上的終結點(diǎn)之間的通信，則需要使用基于消息的安全性。
使用基本身份驗證的 Web 服務(wù)
對于與為基本身份驗證配置的 Web 服務(wù)交互的客戶(hù)端應用程序，客戶(hù)端可以使用登錄對話(huà)框來(lái)接受有效的用戶(hù)憑據，并用它來(lái)進(jìn)行身份驗證。下面的代碼演示了如何為需要基本身份驗證的 Web 服務(wù)代理設置用戶(hù)憑據。
CredentialCache cache = new CredentialCache(); cache.Add( new Uri( service.Url ), // Web service URL. "Basic", // Basic Authentication. new NetworkCredential( userName, password, domain ) ); service.Credentials = cache;
在本例中，userName、password 和 domain 是作為登錄對話(huà)框的一部分被接受的。
HTTP 摘要身份驗證
HTTP 摘要身份驗證提供與 HTTP 基本身份驗證相同的功能，但是采用不同的方式來(lái)傳輸身份驗證憑據。身份驗證憑據是在一種稱(chēng)為哈希 的單向處理中進(jìn)行轉換的。這種處理的結果稱(chēng)為哈希 或 消息摘要，使用當前的技術(shù)不可能對其進(jìn)行解密。
摘要身份驗證按照以下過(guò)程進(jìn)行：
1.
服務(wù)器給瀏覽器發(fā)送將在身份驗證過(guò)程中使用的特定信息。
2.
瀏覽器將此信息以及一些其他信息添加到它的用戶(hù)名和密碼中，然后對其進(jìn)行哈希運算。附加信息有助于防止有人復制哈希值并再次使用它。
3.
得到的哈希連同附加信息以明文的方式通過(guò)網(wǎng)絡(luò )發(fā)送到服務(wù)器。
4.
服務(wù)器將附加信息添加到它所擁有的客戶(hù)端密碼的明文副本中，并對所有的信息進(jìn)行哈希。
5.
服務(wù)器將它接收到的哈希值與它剛產(chǎn)生的哈希值進(jìn)行比較。
6.
只有當兩個(gè)值相同時(shí)才授予訪(fǎng)問(wèn)權限。
附加信息是在哈希之前添加到密碼中的，這樣就沒(méi)有人可以捕獲密碼哈希并利用它來(lái)冒充真實(shí)客戶(hù)端。幫助標識客戶(hù)端、客戶(hù)端計算機和客戶(hù)端所屬的領(lǐng)域或域的值也被添加到密碼中。同時(shí)添加的還有時(shí)間戳，以防止客戶(hù)端在密碼被撤消后還使用密碼。
因為摘要身份驗證以哈希形式通過(guò)網(wǎng)絡(luò )發(fā)送密碼，所以它明顯優(yōu)于基本身份驗證，特別是在使用基本身份驗證而沒(méi)有對通信信道進(jìn)行加密時(shí)。因此，如果可能，您應該使用摘要身份驗證來(lái)代替基本身份驗證。
注如同基本身份驗證的情況一樣，只有在向其發(fā)出請求的域服務(wù)器有請求用戶(hù)的密碼的明文副本時(shí)，摘要身份驗證才完成。因為域控制器有密碼的明文副本，所以您必須確保該服務(wù)器是安全的，不會(huì )受到物理和網(wǎng)絡(luò )攻擊。
基于證書(shū)的身份驗證
通過(guò)使用證書(shū)，客戶(hù)端和服務(wù)器應用程序可以使用計算機上安裝的數字密鑰相互進(jìn)行身份驗證，或建立安全連接?？蛻?hù)端應用程序可以使用客戶(hù)端證書(shū)來(lái)向服務(wù)器標識自己，同樣，服務(wù)器也可以使用服務(wù)器證書(shū)來(lái)向客戶(hù)端標識自己。一個(gè)雙方都信任的第三方（稱(chēng)為證書(shū)頒發(fā)機構）可以確認這些證書(shū)的標識?？蛻?hù)端證書(shū)可以映射到 Microsoft Active Directory? 目錄服務(wù)中的 Microsoft Windows 帳戶(hù)。
您可以建立一個(gè)站點(diǎn)，使沒(méi)有證書(shū)的用戶(hù)以來(lái)賓身份登錄，而有證書(shū)的用戶(hù)以他的或她的證書(shū)所映射的用戶(hù)的身份登錄。然后，您可以基于該證書(shū)自定義站點(diǎn)。
如果您需要對單個(gè)用戶(hù)進(jìn)行身份驗證，您可以使用一種稱(chēng)為“一對一映射”的技術(shù)，這種技術(shù)會(huì )將證書(shū)映射到單個(gè)帳戶(hù)。如果您需要對來(lái)自特定組或組織的所有用戶(hù)進(jìn)行身份驗證，您可以使用多對一映射，例如，它可以將包含共同的公司名稱(chēng)的所有證書(shū)映射到單個(gè)帳戶(hù)。
在基于證書(shū)的身份驗證中，客戶(hù)端應用程序使用的是可以由 Web 服務(wù)進(jìn)行身份驗證的證書(shū)。在這種情況中，客戶(hù)端應用程序使用 X.509 證書(shū)來(lái)對 SOAP 消息進(jìn)行數字簽名，以確保消息來(lái)自受信任的來(lái)源，并且在到達指定的 Web 服務(wù)之前沒(méi)有在傳輸的過(guò)程中被篡改。
基于證書(shū)的身份驗證的一個(gè)主要考慮事項是如何處理證書(shū)將不再有效的情況。例如，如果一個(gè)雇員使用證書(shū)來(lái)進(jìn)行身份驗證，之后該雇員被解雇了，則此證書(shū)應該不再允許該用戶(hù)訪(fǎng)問(wèn)資源。因此，證書(shū)安全性基礎結構包括對證書(shū)撤消列表的管理非常重要。這些列表放在服務(wù)器上，每當客戶(hù)端連接到網(wǎng)絡(luò )資源時(shí)都將進(jìn)行檢查。
當智能客戶(hù)端脫機工作時(shí)，不能對基于服務(wù)器的撤消列表進(jìn)行檢查，因此一個(gè)不能訪(fǎng)問(wèn)服務(wù)器上的資源的用戶(hù)有可能對客戶(hù)端上的資源進(jìn)行本地訪(fǎng)問(wèn)。為了幫助解決這個(gè)問(wèn)題，您可以選擇相對短的客戶(hù)端證書(shū)租約時(shí)間。短的租約時(shí)間會(huì )強制客戶(hù)端定期連接到證書(shū)服務(wù)器，并且在續訂租約和允許連接到服務(wù)器端應用程序之前確認證書(shū)尚未撤消。
有關(guān)詳細信息，請參閱
http://www.microsoft.com/resources/documentation/windowsserv/2003/standard/proddocs/en-us/sec_auth_certabout.asp 上的“About Certificates”。
基于 WSE 的身份驗證
使用 Web Services Enhancements 版本 2.0，可以通過(guò)編程方式簽署 Web 服務(wù)的 SOAP 消息。WSE 2.0 是一個(gè)實(shí)現，它支持各種新興的 Web 服務(wù)標準，例如 WS-Security、WS-SecureConversation、WS-Trust、WS-Policy、WS-Addressing、WS-Referral、WS-Attachments 和 Direct Internet Message Encapsulation (DIME)。WSE 提供一種編程模型來(lái)實(shí)現它所支持的各種規范。
使用 WSE 的客戶(hù)端應用程序可以使用 X509CertificateStore 類(lèi)中的某種 Find 方法（例如 FindCertificateByHash 或 FindCertificateByKeyIdentifier）通過(guò)編程方式從存儲區中選擇一個(gè)證書(shū)，使用該證書(shū)創(chuàng )建數字簽名，將其添加到 WS-Security SOAP 頭并調用 Web 服務(wù)。另外，客戶(hù)端應用程序還可以選擇打開(kāi)當前登錄用戶(hù)的證書(shū)存儲區，如下面的代碼示例所示。
X509CertificateStore store; store = X509CertificateStore.CurrentUserStore( X509CertificateStore.MyStore ); bool open = store.OpenRead();
有關(guān)詳細信息，請參閱
http://msdn.microsoft.com/webservices/building/wse/default.aspx 上的“Web Services Enhancements”。
有關(guān)使用客戶(hù)端證書(shū)的詳細信息，請參閱 WSE 2.0 文檔中的“Signing a SOAP Message Using an X.509 Certificate”。
自定義身份驗證
在某些情況下，Windows 提供的標準身份驗證選擇并不適用于您的應用程序，您將可能需要設計您自己的身份驗證形式。幸運的是，.NET Framework 提供了一些選擇來(lái)幫助您設計自定義身份驗證解決方案。
.NET Framework 支持 IIdentity 的一個(gè)實(shí)現，稱(chēng)為 GenericIdentity。您可以使用 GenericIdentity，也可以創(chuàng )建您自己的自定義標識類(lèi)。設計自定義身份驗證解決方案可能比較困難，因為您必須自己采取措施來(lái)確保方法是安全的。您可能還需要為您的標識維護單獨的存儲區。
收集和驗證用戶(hù)憑據
不管您使用的是什么形式的身份驗證，您都需要收集用戶(hù)憑據，然后可以對其進(jìn)行驗證。對于已經(jīng)使用集成 Windows 身份驗證登錄的用戶(hù)，您可能只需收集現有的憑據，而對于自定義身份驗證解決方案，您可能需要通過(guò)您自己的登錄對話(huà)框來(lái)安全地收集憑據。
注不要將用戶(hù)憑據存儲在代碼中超過(guò)必要的時(shí)間。特別是，不要用全局變量存儲憑據，它們是通過(guò)可公開(kāi)訪(fǎng)問(wèn)的方法或屬性提供訪(fǎng)問(wèn)的，另外，也不要將憑據保存在磁盤(pán)上。
收集當前登錄的用戶(hù)的憑據
如果您使用的是集成 Windows 身份驗證，則您的用戶(hù)是在他們的 Windows 會(huì )話(huà)開(kāi)始時(shí)登錄的。然后，您的應用程序可以使用這一信息來(lái)確保他們具有適當的憑據用于運行。
下面的代碼演示了基本功能。
using System.Security.Principal; // Get principal of the currently logged in user. WindowsPrincipal wp = new WindowsPrincipal( WindowsIdentity.GetCurrent() ); // Display the current user name. label1.Text = "User:" + wp.Identity.Name; // Determine if user is part of a windows group. if( wp.IsInRole( "YourDomain\\YourWindowsGroup" ) ) { // Is a member. } else { // Is not a member. } 使用登錄對話(huà)框收集用戶(hù)憑據
如果您設計您自己的登錄對話(huà)框接受來(lái)自用戶(hù)的憑據，則需要采取大量的措施來(lái)確保您滿(mǎn)足您的組織的安全性要求（例如強制執行強密碼策略和在定期的時(shí)間間隔內讓密碼過(guò)期）。在設計登錄對話(huà)框時(shí)，請考慮使用下列指導原則：
?
不要盲目信任用戶(hù)輸入。如果您盲目信任用戶(hù)輸入，惡意用戶(hù)就可能危及您的應用程序的安全。例如，如果不對動(dòng)態(tài)構造 SQL 代碼進(jìn)行驗證，使用輸入的應用程序就容易受到 SQL 插入攻擊。
?
檢查輸入數據的類(lèi)型、格式或范圍?？紤]使用正則表達式來(lái)進(jìn)行這些檢查。使用正則表達式可以檢查類(lèi)型（例如，字符串或整型）、格式（例如，強制密碼策略要求使用諸如數字、特殊符號及大小寫(xiě)字母字符混合等）和范圍（例如，用戶(hù)名稱(chēng)最少包含 6 個(gè)字符，最多包含 25 個(gè)字符）。
下面的代碼示例強制要求密碼長(cháng)度為 8 至 10 個(gè)字符，并且是大小寫(xiě)字母和數字字符的組合。
// Validate the user supplied password. if( !Regex.Match( textBox1.Text, @"^(?=.*\d)(?=.*[a-z])(?=.*[A-Z]).{8,10}$", RegexOptions.None ).Success ) { // Invalid email address. }
?
在設計帶有密碼字段文本框的對話(huà)框時(shí)，請確保 PasswordChar 屬性設置為當文本輸入控件時(shí)顯示的字符，如下面的示例所示。
// The password character is set to asterisk. textBox1.PasswordChar = ?*‘;
身份驗證指導原則
在為應用程序設計身份驗證時(shí)，應該考慮使用下列指導原則：
?
確定在用戶(hù)與應用程序交互時(shí)什么階段需要進(jìn)行身份驗證。
?
考慮在用戶(hù)登錄到客戶(hù)端時(shí)使用集成 Windows 身份驗證對他們進(jìn)行身份驗證，之后用戶(hù)就可以訪(fǎng)問(wèn)應用程序、應用程序的數據和任何遠程服務(wù)。
?
如果應用程序是集中部署的并且需要將訪(fǎng)問(wèn)僅限于經(jīng)過(guò)授權的用戶(hù)，就應該在應用程序運行時(shí)使用 IIS 提供的身份驗證機制之一對用戶(hù)進(jìn)行身份驗證。
?
如果應用程序提供敏感功能或者提供對本地保存的敏感數據的訪(fǎng)問(wèn)，則應該確保在允許用戶(hù)訪(fǎng)問(wèn)之前對他們進(jìn)行適當的身份驗證。
?
如果應用程序需要自定義身份驗證，則應該確保應用程序強制執行強用戶(hù)名和密碼策略。作為慣例，應該需要最少 8 個(gè)字符和大小寫(xiě)字母字符、數字和特殊字符的混合。
?
如果遠程服務(wù)提供敏感功能或者提供對敏感數據的訪(fǎng)問(wèn)，則需要對用戶(hù)進(jìn)行身份驗證，以便他們通過(guò)網(wǎng)絡(luò )訪(fǎng)問(wèn)遠程服務(wù)。
?
確保用戶(hù)憑據在沒(méi)有保護措施的情況下不通過(guò)網(wǎng)絡(luò )進(jìn)行傳輸。有些身份驗證形式根本不通過(guò)網(wǎng)絡(luò )傳送用戶(hù)憑據，但是如果必須傳送，就應該確保它們經(jīng)過(guò)加密，或者通過(guò)安全連接進(jìn)行傳送。
有關(guān)詳細信息，請參閱 Improving Web Application Security: Threats and Countermeasures 的“Chapter 4 — Design Guidelines for Secure Web Applications”中的“身份驗證”，地址在
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh04.asp。
返回頁(yè)首授權
在對用戶(hù)進(jìn)行身份驗證之后，可以通過(guò)授權來(lái)確定他們有權訪(fǎng)問(wèn)系統內的什么內容。授權是確認經(jīng)過(guò)身份驗證的用戶(hù)具有執行某種操作的權限的過(guò)程。授權管理經(jīng)過(guò)身份驗證的用戶(hù)可以訪(fǎng)問(wèn)的資源（例如，文件和數據庫）和可以執行的操作（例如，更改密碼或刪除文件）。沒(méi)有經(jīng)過(guò)身份驗證的用戶(hù)（即匿名用戶(hù)）不能進(jìn)行特別授權，而是需要分配一組默認權限。
許多因素嚴格地確定了您可以如何在您的環(huán)境中執行授權。您需要確定是基于應用程序的功能還是基于系統資源來(lái)管理授權。您需要確定是執行方法內的細粒度授權還是執行方法級的檢查。此外，您還需要確定在何處存儲授權所需的用戶(hù)信息（例如，在 Active Directory 或 Microsoft SQL Server 數據庫中）。如果您將允許您的智能客戶(hù)端能夠脫機工作，則需要有對脫機客戶(hù)端進(jìn)行授權的策略。
.NET Framework 提供 IPrincipal 接口，它可以與 IIdentity 接口一起，用于定義管理運行代碼的安全上下文的屬性和方法。同時(shí)提供的還有該接口的兩個(gè)實(shí)現：WindowsPrincipal 和 GenericPrincipal。使用集成 Windows 身份驗證的客戶(hù)端應用程序使用的是 WindowsPrincipal，而使用自定義身份驗證的客戶(hù)端應用程序使用的是 GenericPrincipal。
授權的類(lèi)型
Windows 操作系統中常用的授權方法有兩種：基于資源的授權和基于角色的授權?；谫Y源的授權依賴(lài)于訪(fǎng)問(wèn)控制列表 (ACL)，而基于角色的授權則基于用戶(hù)角色執行授權。
基于資源的授權
對于基于資源的授權，可以將任意訪(fǎng)問(wèn)控制列表 (DACL) 附加到保險對象。然后，系統作出訪(fǎng)問(wèn)決定，方法是比較令牌中的組成員身份與 ACL 的內容，以確定該用戶(hù)是否具有所請求的訪(fǎng)問(wèn)權限。對于許多類(lèi)型的應用程序，ACL 模型是非常理想的。然而，它并非適合于所有的情況。例如，您可能需要基于業(yè)務(wù)邏輯或者基于在需要時(shí)創(chuàng )建的非持久性對象來(lái)作出訪(fǎng)問(wèn)決定。
基于角色的授權
基于角色的授權允許您將用戶(hù)和組與他們完成其工作所需的權限相關(guān)聯(lián)。當將一個(gè)用戶(hù)或組添加到一個(gè)角色中時(shí)，該用戶(hù)或組就會(huì )自動(dòng)地繼承各種安全權限。這些權限可以是執行操作的權限，也可以是訪(fǎng)問(wèn)各種資源的權限。圖 5.1 說(shuō)明了基于角色的授權中角色與權限之間的關(guān)系。
圖 5.1 基于角色的授權
在 Microsoft Windows 2000 Server Service Pack 4 (SP4) 和 Windows Server 2003 操作系統中，基于角色的授權通常是通過(guò)授權管理器管理的。授權管理器是一組基于 COM 的運行時(shí)接口、以及用于配置的 Microsoft 管理控制臺 (MMC) 管理單元。開(kāi)發(fā)人員可以使用授權管理器確保應用程序能夠管理和驗證客戶(hù)端對執行應用程序操作的請求，而應用程序管理員則可以用它來(lái)管理用戶(hù)角色和權限。通過(guò)使用授權管理器，可以將低級操作聚集成稱(chēng)為“Tasks”的組，并管理這一級別的授權。同時(shí)它還使得您能夠在授權前后運行自定義授權邏輯。
授權管理器的一個(gè)顯著(zhù)優(yōu)點(diǎn)是，它可以從需要授權的應用程序中進(jìn)一步抽象授權存儲，這意味著(zhù)開(kāi)發(fā)人員可以一直與授權管理器通信，而不管存儲是在 Active Directory 中還是基于文件的。
給應用程序添加授權功能
.NET Framework 提供了許多選擇來(lái)給應用程序添加授權功能。這些選擇包括：
?
使用 PrincipalPermissionAttribute 執行聲明性 Demand。
?
使用 PrincipalPermission 對象執行命令性 Demand。
?
使用 IsInRole 方法執行角色檢查。
?
執行用于自定義身份驗證的角色檢查。
使用 PrincipalPermissionAttribute 執行聲明性 Demand
可以將 Demand 放在類(lèi)級或成員級的單個(gè)方法、屬性或事件上。如果將聲明性 Demand 同時(shí)放在類(lèi)級和成員級上，則成員級的聲明性 Demand 會(huì )重寫(xiě)（或替換）類(lèi)級的 Demand。
下面的代碼示例顯示了 PrincipalPermission 對象的聲明性 Demand。
// Declarative example. [PrincipalPermissionAttribute( SecurityAction.Demand, Role="Teller" )] void SomeTellerOnlyMethod() { } 使用 PrincipalPermission 對象執行命令性 Demand
可以執行命令性 Demand，方法是通過(guò)編程方式調用 PrincipalPermission 對象的 Demand 方法，如下面的代碼示例所示。
// Programmatic example. public SomeMethod() { PrincipalPermission permCheck = new PrincipalPermission( null, "Teller" ); permCheck.Demand(); // Only Tellers can execute the following code. // Non members of the Teller role result in a security exception. . . . }
通過(guò)編程方式調用該方法的一個(gè)優(yōu)點(diǎn)是，可以確定主體是否在多個(gè)角色中。.NET Framework 不允許以聲明的方式這樣做。下面的代碼示例顯示了如何執行這一檢查。
// Using PrincipalPermission. PrincipalPermission permCheckTellers = new PrincipalPermission( null, "Teller" ); permCheckTellers.Demand(); PrincipalPermission permCheckMgr = new PrincipalPermission( null, "Manager" ); permCheckMgr.Demand(); 使用 IsInRole 方法執行角色檢查
可以選擇直接訪(fǎng)問(wèn)主體對象的值并執行檢查，而不使用 PrincipalPermission 對象。在這種情況下，可以讀取當前線(xiàn)程的主體的值，也可以使用 IsInRole 方法來(lái)執行授權，如下面的代碼示例所示。
// Using IsInRole. if ( Thread.CurrentPrincipal.IsInRole( "Teller" ) && Thread.CurrentPrincipal.IsInRole( "Manager" ) ) { // Perform privileged operation. } 執行用于自定義身份驗證的角色檢查
如果應用程序不是基于 Windows 的，則可以通過(guò)編程方式將一組從自定義身份驗證數據存儲區（例如 SQL Server 數據庫）中獲得的角色填充 GenericPrincipal 對象，如下面的代碼示例所示。
GenericIdentity userIdentity = new GenericIdentity( "Bob" ); // Typically role names would be retrieved from a custom data store. string[] roles = new String[]{ "Manager", "Teller" }; GenericPrincipal userPrincipal = new GenericPrincipal( userIdentity, roles ); if ( userPrincipal.IsInRole( "Teller" ) ) { // Perform privileged operation. } 授權指導原則
授權對控制用戶(hù)訪(fǎng)問(wèn)應用程序功能和資源的權限非常關(guān)鍵。不適當的或弱的授權會(huì )導致信息泄露和數據篡改。請考慮使用下列指導原則：
?
盡可能地使用多個(gè)網(wǎng)關(guān)守衛以在用戶(hù)訪(fǎng)問(wèn)資源或執行操作時(shí)強制執行授權檢查。使用客戶(hù)端檢查和服務(wù)器上的檢查相結合的方法來(lái)提供深層防御，以防止設法繞開(kāi)其中一個(gè)網(wǎng)關(guān)守衛的惡意用戶(hù)的攻擊。服務(wù)器上常見(jiàn)的網(wǎng)關(guān)守衛包括 IIS Web 權限、NTFS 文件系統權限、Web 服務(wù)文件授權（只適用于 Windows 身份驗證）和主體權限 Demand。
?
使用用戶(hù)的安全上下文授權訪(fǎng)問(wèn)系統資源?？梢允褂没诮巧氖跈鄟?lái)基于用戶(hù)標識和角色成員身份授權訪(fǎng)問(wèn)。集成 Windows 身份驗證與安全資源（例如文件或注冊表）上的 Windows ACL 共同確定是否允許調用者訪(fǎng)問(wèn)資源。對于程序集，可以基于諸如程序集的強名稱(chēng)或位置等證據來(lái)授權調用代碼。
?
確保使用足夠的粒度來(lái)定義角色，以便充分分離特權。避免只為滿(mǎn)足某些用戶(hù)的要求而授予提高的特權；相反，考慮添加新的角色來(lái)滿(mǎn)足這些要求。
?
盡可能地使用聲明性 Demand 而非命令性 Demand。聲明性 Demand 提供或拒絕對方法的全部功能的訪(fǎng)問(wèn)。另外，它們還可以更好地與安全工具一起使用，并且有助于進(jìn)行安全審核，因為這些工具能夠通過(guò)檢驗應用程序來(lái)訪(fǎng)問(wèn)這些 Demand。
?
如果您需要確定主體是否在多個(gè)角色中，則可以考慮使用 IsInRole 方法進(jìn)行命令性檢查。.NET Framework 版本 1.1 不允許以聲明的方式執行 AND 檢查；然而，可以通過(guò)編程的方式在方法內執行它們，如下面的代碼示例所示。
// Checking for multiple roles. if ( Thread.CurrentPrincipal.IsInRole( "Teller" ) && Thread.CurrentPrincipal.IsInRole( "Manager" ) ) { // Perform privileged operation. }
?
使用代碼訪(fǎng)問(wèn)安全來(lái)授權調用對特權資源或操作的代碼訪(fǎng)問(wèn)（基于諸如程序集的強名稱(chēng)或位置這樣的證據）。有關(guān)詳細信息，請參閱本章后面的“代碼訪(fǎng)問(wèn)安全”。
客戶(hù)端脫機時(shí)授權使用功能
當用戶(hù)連接到網(wǎng)絡(luò )時(shí)，可以直接根據網(wǎng)絡(luò )授權存儲對他們進(jìn)行授權；但是當他們沒(méi)有連接到網(wǎng)絡(luò )時(shí)，仍然可能需要對他們進(jìn)行授權。
任何形式的授權都不會(huì )比所使用的身份驗證機制更強。如果您允許匿名身份驗證，您就應該特別注意允許用戶(hù)訪(fǎng)問(wèn)什么功能，并且通常不應該授權用戶(hù)訪(fǎng)問(wèn)系統資源。
如果您授權用戶(hù)使用應用程序，則可以讓 Windows 擔當唯一的網(wǎng)關(guān)守衛來(lái)確定哪些資源可用于已登錄用戶(hù)的配置文件。在這種情況下，通常只允許用戶(hù)訪(fǎng)問(wèn)本地系統資源。
您可以選擇為不同的角色創(chuàng )建同一個(gè)應用程序的不同版本。當用戶(hù)連接到網(wǎng)絡(luò )時(shí)，他或她只被允許安裝與其角色相符的應用程序版本。然后，當用戶(hù)脫機運行應用程序時(shí)，無(wú)需為應用程序建立連接即可自動(dòng)提供正確的功能。
授權和配置文件應用程序塊
Microsoft 提供了一個(gè)應用程序塊，它能夠提供基礎結構來(lái)簡(jiǎn)化在應用程序中加入授權功能的過(guò)程。
授權和配置文件應用程序塊為基于角色的授權和對配置文件信息的訪(fǎng)問(wèn)提供基礎結構。該應用程序塊允許您執行下列操作：
?
對應用程序或系統的用戶(hù)進(jìn)行授權。
?
使用多個(gè)授權存儲提供程序。
?
插入操作驗證的業(yè)務(wù)規則。
?
將多個(gè)標識映射到單個(gè)用戶(hù)，從而將標識的概念擴展到包括身份驗證方式。
?
訪(fǎng)問(wèn)可以存儲在多個(gè)配置文件存儲區中的配置文件信息。
有關(guān)詳細信息，請參閱
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/authpro.asp 上的 Authorization and Profile Application Block。
返回頁(yè)首輸入驗證
輸入驗證不嚴格的應用程序可能會(huì )受到攻擊者惡意輸入的威脅。驗證用戶(hù)輸入是保護應用程序的最前沿防線(xiàn)中的一道防線(xiàn)。請考慮使用下面針對智能客戶(hù)端應用程序的輸入驗證指導原則：
?
確保智能客戶(hù)端應用程序在處理輸入或將輸入傳送到下游資源和程序集之前驗證了所有的輸入。
?
如果您要將輸入數據傳送給非托管 API，請對用戶(hù)輸入數據進(jìn)行徹底的驗證。這樣做有助于防止緩沖區溢出。您還應該限制用戶(hù)輸入傳送到非托管 API 的數據。
?
始終驗證從所有外部來(lái)源（例如 Web 站點(diǎn)和 Web 服務(wù)）獲得的數據。
?
切勿依賴(lài)對傳送到 Web 服務(wù)器或者 Web 應用程序的數據進(jìn)行的客戶(hù)端驗證。首先在客戶(hù)端驗證數據，然后再次在服務(wù)器上驗證數據，以便防止繞過(guò)客戶(hù)端驗證的惡意輸入。
?
切勿允許用戶(hù)直接輸入 SQL 查詢(xún)。始終提供針對安全問(wèn)題進(jìn)行了徹底的檢查的預先打包的或參數化查詢(xún)。允許用戶(hù)直接輸入 SQL 查詢(xún)可能帶來(lái) SQL 插入攻擊。
?
用已知的正確值或模式（而不是用錯誤的輸入）來(lái)約束并驗證用戶(hù)輸入。檢查一個(gè)有限已知值的列表比檢查一個(gè)無(wú)限未知惡意輸入類(lèi)型的列表簡(jiǎn)單得多。在對輸入值采取行動(dòng)之前,既可以拒絕有害的輸入，也可以對輸入進(jìn)行凈化（即除去潛在的不安全字符）。
?
通過(guò)驗證輸入的類(lèi)型、長(cháng)度、格式和范圍來(lái)約束它。一種這樣做的方法就是使用正則表達式（可以從 System.Text.RegularExpressions 命名空間中獲得）來(lái)驗證用戶(hù)輸入。
?
拒絕未知的有害數據，然后凈化輸入。如果應用程序需要接受某些自由格式的用戶(hù)輸入（例如，文本框中的注釋?zhuān)?，可以對輸入進(jìn)行凈化，如下面的示例所示：
private string SanitizeInput( string input ) { // Example list of characters to remove from input. Regex badCharReplace = new Regex( @"([<>""?%;()&])" ); string goodChars = badCharReplace.Replace( input, "" ); return goodChars; }
?
考慮集中驗證例程，以減少開(kāi)發(fā)工作量并有助于未來(lái)的維護。
有關(guān)詳細信息，請參閱 Improving Web Application Security: Threats and Countermeasures 的“Chapter 4 — Design Guidelines for Secure Web Applications”中的“輸入驗證”，地址在
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh04.asp。
返回頁(yè)首處理敏感數據
如果您經(jīng)常設計 Web 應用程序，您就會(huì )理解保護存儲的數據和傳輸的數據的重要性。存儲在 Web 服務(wù)器上的數據通常被寫(xiě)入物理上安全的位置，這樣的位置已經(jīng)很好地被保護起來(lái)以防止受到攻擊。在智能客戶(hù)端應用程序中，您同樣需要仔細考慮駐留在客戶(hù)端上的數據。如果這些數據是敏感的，適當地對其進(jìn)行處理以確保安全就非常重要。為了保護傳輸的數據，您可以使用 SSL 保護傳輸層，并且使用 WS-Security 或 Message Queuing 加密工具保護消息內容。
只有授權用戶(hù)訪(fǎng)問(wèn)的數據才應該可用于客戶(hù)端應用程序。如果一臺計算機上的多個(gè)人都可以使用客戶(hù)端應用程序，則與每個(gè)單獨的用戶(hù)相關(guān)的數據都應該被認為是敏感數據，并且應該采取一些措施來(lái)確保只有經(jīng)過(guò)授權的用戶(hù)可以訪(fǎng)問(wèn)它。
敏感數據包括攻擊者可能發(fā)現對訪(fǎng)問(wèn)或修改有用的任何數據，因為這些信息是機密的或者對攻擊有幫助。敏感數據可以是服務(wù)器提供給客戶(hù)端的數據，但也可以包括應用程序配置文件、本地數據庫或注冊表信息。
在通常情況下，應該盡力確保敏感數據不本地緩存。然而，在智能客戶(hù)端應用程序的情況下，可能需要緩存這些數據（例如，為允許偶爾連接的操作，將數據保存在本地存儲區以供日后使用）。
注在某些情況下，敏感數據可能由于內存中的分頁(yè)而發(fā)送到磁盤(pán)上。因此，在確定需要對什么樣的數據進(jìn)行加密時(shí)，也應該考慮存在于內存中的數據。
確定將哪些數據存儲在客戶(hù)端上
根據定義，用戶(hù)（因而是潛在的攻擊者）可以在物理上接觸客戶(hù)端。如果給予足夠的時(shí)間，攻擊者常常能夠獲得足夠的管理權限來(lái)訪(fǎng)問(wèn)幾乎任何數據，因此您應該仔細考慮應該將什么樣的數據存放在客戶(hù)端。作為一般的規則，您應該對服務(wù)器進(jìn)行授權決策，這樣，就只有您從服務(wù)器傳送到客戶(hù)端的數據是允許用戶(hù)訪(fǎng)問(wèn)的數據。除了提高性能之外，對服務(wù)器進(jìn)行授權決策也可以確保這種數據不會(huì )被客戶(hù)端上的潛在攻擊者訪(fǎng)問(wèn)得到。
您應該從不將敏感數據存儲在基于文本的文件中，并且應該始終對這些數據進(jìn)行加密，這樣就只有經(jīng)過(guò)授權的用戶(hù)才可以輕松地進(jìn)行訪(fǎng)問(wèn)。您應該避免使用基于文本的配置文件來(lái)存儲敏感的安全信息，例如密碼或數據庫連接字符串。如果這些信息必須在本地存儲，您就應該對信息進(jìn)行加密，并將其存儲在文件或注冊表項中，然后使用 DACL 來(lái)限制對該對象的訪(fǎng)問(wèn)。此外，還必須保護針對登錄用戶(hù)個(gè)人的任何永久性數據的隱私和安全，特別是當計算機在用戶(hù)之間共享時(shí)。
在許多情況下，如果應用程序需要脫機運行，則較多的數據就會(huì )存儲在客戶(hù)端上。然而，您應該確定脫機時(shí)是否需要所有的數據，或者是否您想要限制用戶(hù)在脫機時(shí)執行某些操作，這樣您就不必將敏感數據緩存在本地。
在某些情況下，如果數據是機密的，并且可以按需要由用戶(hù)輸入，則可以選擇根本不將數據本地存儲在客戶(hù)端上，而是在需要時(shí)從用戶(hù)獲得。
如果應用程序需要在本地存儲敏感數據，通常應該避免使用可移動(dòng)存儲器（例如軟盤(pán)、zip 磁盤(pán)、或 USB 存儲設備）或外部便攜式存儲器來(lái)存儲敏感數據。然而，當可以確?？梢苿?dòng)媒體為該用戶(hù)所有（例如，通過(guò)使用證書(shū)或智能卡）時(shí)，就可以將特定于用戶(hù)的數據存儲在可移動(dòng)媒體中。因此，可以將特定于用戶(hù)的數據存放在隨用戶(hù)一起移動(dòng)的安全位置，這樣，漫游用戶(hù)就可以在不將數據保留在本地計算機上的情況下訪(fǎng)問(wèn)應用程序及其數據。
注當考慮將哪些敏感數據存儲在客戶(hù)端上時(shí)，您應該確保存儲關(guān)于雇員或顧客的信息沒(méi)有違反隱私法規。這些法律因國家/地區而異，因此您應該熟悉使用您的應用程序的國家/地區的隱私法規。
保護敏感數據的技術(shù)
對于需要存儲在客戶(hù)端上的數據，有許多可以采取的附加措施來(lái)防止未經(jīng)授權的訪(fǎng)問(wèn)。這些措施包括下列內容：
?
確保只有經(jīng)過(guò)授權的用戶(hù)才可以訪(fǎng)問(wèn)數據。
?
考慮使用 EFS 加密文件。
?
考慮使用 DPAPI 避免密鑰管理問(wèn)題。
?
考慮存儲哈希值而不是明文。
?
考慮部分受信任的應用程序的隔離存儲。
?
保護私鑰。
確保只有經(jīng)過(guò)授權的用戶(hù)才可以訪(fǎng)問(wèn)數據
數據常常需要進(jìn)行保護，以幫助確保只有經(jīng)過(guò)授權的用戶(hù)才可以訪(fǎng)問(wèn)。取決于應用程序的性質(zhì)和數據保持有效的時(shí)間，可以選擇使用基于資源的安全性或基于角色的安全性來(lái)保護數據。有關(guān)詳細信息，請參閱本章前面的“授權指導原則”。
考慮使用 EFS 加密文件
確保將文件安全地存放在智能客戶(hù)端上的一種方法是使用加密文件系統 (Encrypting File System, EFS) 對敏感數據文件進(jìn)行加密。這個(gè)解決方案在可擴展方面乏善可陳；然而，它對某些特定的文件非常有用，它也可以用于在客戶(hù)端上本地緩存數據的情況（例如，用于啟用偶爾連接的智能客戶(hù)端）。
考慮使用 DPAPI 避免密鑰管理問(wèn)題
Windows 2000 和 Windows 操作系統的更高版本提供了用于加密和解密數據的 Win32? 數據保護 API (DPAPI)。它是加密 API (Crypto API) 的一部分，并且是用 crypt32.dll 實(shí)現的。它包含兩個(gè)方法：CryptProtectData 和 CryptUnprotectData。
DPAPI 特別有用，因為它可以消除暴露給使用密碼的應用程序的密鑰管理問(wèn)題。雖然加密可以確保數據是安全的，但是您必須采取額外的步驟來(lái)確保密鑰的安全。為了派生加密密鑰，DPAPI 使用與調用 DPAPI 函數的代碼相關(guān)的用戶(hù)帳戶(hù)的密碼。因此，是由操作系統（而不是由應用程序）管理密鑰。
DPAPI 可以與機器存儲區或用戶(hù)存儲區一起工作。用戶(hù)存儲區是基于登錄用戶(hù)的配置文件自動(dòng)加載的?？蛻?hù)端應用程序通常與用戶(hù)存儲區一起使用 DPAPI，除非需要存儲為所有可以登錄到計算機的用戶(hù)共有的機密。
DPAPI 用來(lái)加密和解密敏感數據的密鑰是特定于計算機的。系統會(huì )為每臺計算機生成一個(gè)不同的密鑰，這可以防止一個(gè)服務(wù)器能夠訪(fǎng)問(wèn)由另一個(gè)服務(wù)器加密的數據。
非托管 DPAPI 需要程序集具有完全的信任。具有完全和部分受信任的程序集的應用程序可以使用高特權來(lái)分離代碼，并且使其能夠從部分受信任的代碼中進(jìn)行調用。有關(guān)更多信息，請參閱
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secmod/html/secmod115.asp 上的“How To Create a Custom Encryption Permission”。
考慮存儲哈希值而不是明文
有時(shí)，存儲數據是為了使之可以用于驗證用戶(hù)輸入（例如，用戶(hù)名和密碼的組合）。在這樣的情況下，可以存儲數據的加密哈希，而不是以明文的形式存儲數據本身。然后，當用戶(hù)進(jìn)行輸入時(shí)，還可以對該數據進(jìn)行哈希運算，并且可以比較兩個(gè)哈希。存儲哈希減少了機密被發(fā)現的風(fēng)險，因為從其哈希推導原始數據或從其他數據生成相同的哈希在計算上是不可能的。
考慮部分受信任的應用程序的隔離存儲
隔離存儲允許應用程序將數據保存到唯一的數據艙，數據艙與代碼的標識的某些方面相關(guān)聯(lián)，例如它的 Web 站點(diǎn)、發(fā)布者或簽名。數據艙是一個(gè)抽象的概念，而不是一個(gè)具體的存儲位置；它由一個(gè)或多個(gè)隔離的存儲文件（稱(chēng)為存儲）組成，存儲包含存儲數據的實(shí)際目錄位置。
對于需要存儲特定于特定用戶(hù)和程序集的狀態(tài)數據的部分受信任的應用程序，隔離存儲特別有用。部分受信任的應用程序并不直接訪(fǎng)問(wèn)文件系統來(lái)保持狀態(tài)，除非通過(guò)更改安全策略顯式地授予它們這樣做的權限。
存儲在隔離存儲中的數據是隔離的，并且受到保護，不會(huì )被其他部分受信任的應用程序訪(fǎng)問(wèn)，但是無(wú)法保護它不會(huì )被完全受信任的代碼或有權訪(fǎng)問(wèn)客戶(hù)端計算機的其他用戶(hù)訪(fǎng)問(wèn)。為了在這些情況下保護數據，您應該通過(guò)使用 DACL 采用數據加密或者文件系統安全性。有關(guān)詳細信息，請參閱
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconIntroductionToIsolatedStorage.asp 上的 .NET Framework Developer‘s Guide 中的“Introduction to Isolated Storage”。
保護私鑰
未受保護的私鑰易于受到惡意用戶(hù)或惡意代碼進(jìn)行的各種各樣的攻擊。用于簽署程序集的私鑰不應該放在不安全的位置，例如開(kāi)發(fā)人員的計算機或開(kāi)放共享的環(huán)境。攻擊者可以使用竊取的私鑰簽署帶有您的強名稱(chēng)的惡意代碼。您確實(shí)應該通過(guò)您的組織內為此目的而指定的中央安全機構來(lái)保護您的私鑰。您也可以將私鑰保存在物理上安全的隔離計算機上，并且在必要時(shí)使用便攜式媒體來(lái)傳遞密鑰。
有關(guān)有效地存儲機密的詳細信息，請參閱 Michael Howard 和 David LeBlanc 撰寫(xiě)的 Writing Secure Code, Second Edition。
返回頁(yè)首代碼訪(fǎng)問(wèn)安全
代碼訪(fǎng)問(wèn)安全是 .NET Framework 技術(shù)，它將身份驗證和授權原則應用于代碼而不是用戶(hù)。代碼訪(fǎng)問(wèn)安全是一種強大的機制，它確保只有用于運行的代碼才可以被用戶(hù)運行。
所有的托管代碼都遵循代碼訪(fǎng)問(wèn)安全機制。當加載一個(gè)程序集時(shí)，會(huì )授予它一組代碼訪(fǎng)問(wèn)權限，以確定它可以訪(fǎng)問(wèn)什么資源和執行什么類(lèi)型的特權操作。為了授予這些權限，.NET Framework 安全系統使用證據來(lái)對代碼進(jìn)行身份驗證（標識）。
注 程序集是代碼訪(fǎng)問(wèn)安全的配置和信任單元。相同程序集中的所有代碼都接收相同的權限，因而是同等受信任的。
代碼訪(fǎng)問(wèn)安全包括下列要素：
?
權限。權限代表代碼訪(fǎng)問(wèn)安全資源或執行特權操作的權力。Microsoft .NET Framework 提供代碼訪(fǎng)問(wèn)權限 和代碼標識權限。代碼訪(fǎng)問(wèn)權限封裝訪(fǎng)問(wèn)特特定資源或者執行特定特權操作的能力。例如，在應用程序可以執行任何文件的 I/O 操作之前都需要 FileIOPermission。代碼標識權限用來(lái)基于調用代碼的標識的某個(gè)方面（例如，代碼的強名稱(chēng)）限制對代碼的訪(fǎng)問(wèn)。
?
權限集。.NET Framework 定義了許多權限集，它們代表一組通常作為一個(gè)整體分配的權限。例如，.NET Framework 定義的 FullTrust 權限集將所有的權限分配給完全受信任的代碼；而 LocalIntranet 權限集則分配數量非常有限的權限。
?
證據。.NET Framework 安全系統使用證據來(lái)標識程序集。代碼訪(fǎng)問(wèn)安全策略使用證據來(lái)幫助將恰當的權限授予恰當的程序集。證據可以是位置相關(guān)的（例如，URL、站點(diǎn)、應用程序目錄或區域），也可以是作者相關(guān)的（例如，強名稱(chēng)、發(fā)布者或哈希）。
?
策略。代碼訪(fǎng)問(wèn)安全策略是由管理員配置的，它確定授予程序集的權限。策略可以建立在企業(yè)、機器、用戶(hù)和應用程序域級別上。每個(gè)策略都用一個(gè) XML 配置文件定義。
?
代碼組。每個(gè)策略文件都包含一些分層代碼組。代碼組用來(lái)給程序集分配權限。代碼組由成員身份條件（基于證據）和權限集組成。.NET Framework 定義了許多默認的代碼組，例如 Internet、本地 Intranet、受限制的和受信任的區域。
有關(guān)代碼訪(fǎng)問(wèn)安全的詳細信息，請參閱
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh07.asp 上的 Improving Web Application Security: Threats and countermeasures：“Chapter 7 — Building Secure Assemblies”和
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp 上的“Chapter 8 — Code Access Security in Practice”。
代碼訪(fǎng)問(wèn)安全權限解析
代碼訪(fǎng)問(wèn)安全使用圖 5.2 中概述的步驟來(lái)確定將哪些權限分配給程序集。
圖 5.2 確定將哪些權限分配給程序集
下面的步驟更詳細地描述了這些過(guò)程：
1.
加載程序集，收集證據并將其提供給主機。
2.
根據用于宿主環(huán)境的安全策略來(lái)評估證據。
3.
這種評估的輸出是一組授予程序集的權限。這些權限定義了在此環(huán)境中程序集能夠做什么和不能做什么。
4.
當程序集請求執行特權操作時(shí)，系統就會(huì )將操作的請求與程序集的權限進(jìn)行比較。如果程序集具有這樣的權限，就允許代碼執行該操作，否則，引發(fā)安全異常。
代碼訪(fǎng)問(wèn)安全設計
分配給代碼的權限取決于與代碼相關(guān)的證據和客戶(hù)端計算機上的適當安全策略。為了在保持應用程序的功能的同時(shí)確保其安全，您需要仔細考慮應用程序所需的權限、以及授予這些權限的方式。
授予所有權限的應用程序（這些應用程序定義在 FullTrust 權限集中）稱(chēng)為完全受信任的應用程序。沒(méi)有授予所有權限的應用程序稱(chēng)為部分受信任的應用程序。
在理論上，將應用程序設計為部分受信任通常更可取。然而，智能客戶(hù)端應用程序常常需要執行許多部分受信任的應用程序在默認情況下不能執行的操作。這些操作包括：
?
訪(fǎng)問(wèn)運行應用程序的服務(wù)器以外的服務(wù)器，或者訪(fǎng)問(wèn)使用不同協(xié)議的服務(wù)器。
?
訪(fǎng)問(wèn)本地文件系統。
?
訪(fǎng)問(wèn)本地 Microsoft Office 應用程序并與其交互。
?
訪(fǎng)問(wèn)并與非托管代碼（例如 COM 對象）交互。
如果需要智能客戶(hù)端執行這些種類(lèi)的操作，則應該考慮使它成為一個(gè)完全受信任的應用程序，或者授予它正確地進(jìn)行操作所需的其他特定權限。
注在默認情況下，使用無(wú)接觸部署方式部署的應用程序自動(dòng)成為部分受信任的。如果智能客戶(hù)端需要執行部分受信任的應用程序不能執行的額外操作，則需要部署新的安全策略或者使用其他方法來(lái)部署應用程序。
設計和構建部分受信任的應用程序可能比較復雜，但是仔細考慮并限制授予應用程序的權限有助于確保應用程序不能執行不恰當的操作或者訪(fǎng)問(wèn)明顯不需要的資源。
所有的代碼在運行之前都必須給其授予運行的權限，但是訪(fǎng)問(wèn)安全資源或者執行其他安全敏感操作（例如調用非托管代碼或訪(fǎng)問(wèn)本地文件系統）的代碼必須由 .NET Framework 授予額外的權限才能運行。這樣的代碼稱(chēng)為特權代碼。相反，非特權代碼并不需要訪(fǎng)問(wèn)敏感資源，而只是需要運行的權限。當設計和構建應用程序及其程序集時(shí)，應該標識特權和非特權代碼并將其存檔。這樣做有助于確定代碼需要的權限。
還應該仔細檢驗 .NET Framework 使用哪些證據來(lái)給代碼分配權限。只有在中心位置安全的情況下才應該考慮基于應用程序的位置（例如，文件共享或 Web 服務(wù)器）的證據。類(lèi)似地，只有在密鑰安全的情況下才應該使用具有基于一般密鑰 — 用于簽署所有的代碼（例如，由組織的 IT 部門(mén)）— 的證據的應用程序。然而，依賴(lài)于強名稱(chēng)證據而不是任何基于位置的證據（例如 Web 服務(wù)器地址）通常更安全一些。
設計部分受信任的應用程序
當設計部分受信任的應用程序時(shí)，請遵循下列指導原則：
?
了解應用程序的部署方案。
?
避免引起異常的權限請求。
?
對部分受信任的調用程序使用 Demand/Assert 模式。
?
考慮對程序集使用強名稱(chēng)。
?
避免給受限區域賦予完全的信任。
了解應用程序的部署方案
在設計期間應該清楚地了解應用程序的部署方案，因為部署應用程序的位置對默認授予應用程序的權限有很大的影響。諸如顯示對話(huà)框（例如，使用 SaveFileDialog）或訪(fǎng)問(wèn)系統資源的應用程序功能都可能因為應用程序的部署位置而受到限制。
特別地，授予應用程序的權限取決于它所在的區域（例如，Internet 區域、本地 Intranet 區域或受信任的區域）。用戶(hù)可以對受信任的區域內的應用程序的成員身份有一定的控制，但是不應該依賴(lài)用戶(hù)將應用程序放在此區域來(lái)確保正確的功能。您應該這樣設計您的應用程序，使之在運行時(shí)被授予的權限不夠時(shí)會(huì )正常地失敗。
如果用戶(hù)嘗試執行某種操作，而應用程序卻沒(méi)有足夠的權限來(lái)執行該操作，則這種嘗試可能會(huì )導致失敗的權限請求，這又會(huì )引發(fā)安全異常。應用程序需要處理這些異常，否則它就會(huì )出現故障。您應該確?？梢院芎玫靥幚磉@樣的故障，并且應該給用戶(hù)提供足夠的信息來(lái)解決問(wèn)題，而同時(shí)不泄露與安全有關(guān)的不適當的或敏感的信息。
注系統可以按照使用 .NET Framework 2.0 版本的 ClickOnce 部署功能部署的應用程序的部署清單授予它們特定的權限。在部署應用程序時(shí)，授予的權限將固定，而且將應用程序的位置放在受信任的區域中不會(huì )影響授予的權限。
避免引起異常的權限請求
確定每個(gè)應用程序功能在不引起異常的情況下正確地運行所需的權限。請考慮使用如下措施：
?
設計一個(gè)替代解決方案來(lái)避免可能引起異常的權限請求。例如，對于基于 Intranet 的應用程序，您可以使用 OpenFileDialog 來(lái)顯示一個(gè)對話(huà)框，指示用戶(hù)選擇文件，而不要讓?xiě)贸绦蜃詣?dòng)從硬盤(pán)打開(kāi)并讀取文件。
?
適當地處理異常的檢查權限（特別是 SecurityException）。在您的代碼中，您可以創(chuàng )建一個(gè)特定于您正試圖訪(fǎng)問(wèn)的資源的權限類(lèi)的實(shí)例，并且在訪(fǎng)問(wèn)資源之前檢查必要的權限。例如，當您必須使用 OpenFileDialog 或 SaveFileDialog 顯示對話(huà)框時(shí)，可以使用 FileDialogPermission 類(lèi)和 SecurityManager.IsGranted 靜態(tài)方法來(lái)檢查權限，如下所示。
FileDialogPermission fileDialogPermission = new FileDialogPermission( FileDialogPermissionAccess.Save ); if ( !SecurityManager.IsGranted( fileDialogPermission ) ) { // Not allowed to save file. }
注IsGranted 并不保證操作將成功，因為它沒(méi)有遍歷堆棧來(lái)確定是否所有的上游代碼都具有必需的權限。
?
考慮原型設計并對各種部署區域測試您的應用程序方案：
?
如果您的應用程序設計成能從文件共享運行，您可以將該應用程序的地址設置為網(wǎng)絡(luò )共享（例如，\\MachineName\c$\YourAppPath\YourApp.exe）并從您的硬盤(pán)運行它來(lái)模擬這種方案。
?
如果您的應用程序設計成是從 Web Internet 區域運行，您可以使用您的計算機的 IP 地址（例如，\\<MachineIPaddress\c$\YourAppPath\YourApp.exe）來(lái)模擬這種方案。
對部分受信任的調用程序使用 Demand/Assert 模式
Demand/Assert 模式用于完全受信任的程序集中，以允許部分受信任的調用程序在調用時(shí)訪(fǎng)問(wèn)特權操作。當部分受信任的調用程序需要以安全的方式執行特權操作而又不具有必要的特權時(shí)，這種模式非常有用。通過(guò)使用 Assert，您可以擔保您的代碼的調用程序是值得信任的。
注只有當您完全理解它的使用可能帶來(lái)的安全風(fēng)險時(shí)，才能使用 Demand/Assert 模式。斷言權限關(guān)閉了正常的 .NET Framework 權限檢查，這種權限檢查會(huì )檢查堆棧中所有的調用代碼。關(guān)閉這種機制可能會(huì )將嚴重的安全漏洞引入代碼中，因此只有在您完全理解該模式的含義并用盡所有其他可能的解決方案時(shí)，才能?chē)L試這種模式。
在這種模式中，Demand 調用發(fā)生在 Assert 調用之前。Demand 查看調用程序是否具有該權限，然后，Assert 關(guān)閉特定權限的堆棧遍歷，這樣公共語(yǔ)言運行庫就不會(huì )檢查調用程序是否具有適當的權限。
為了讓部分受信任的調用程序成功地調用完全受信任的程序集方法，可以請求適當的權限來(lái)確保部分受信任的調用程序不會(huì )損害系統，然后斷言特定的權限以執行高特權操作。
在進(jìn)行特權操作之前，應該調用完全受信任的程序集中的 Assert，并隨后調用 RevertAssert以確保方法調用后面的代碼不會(huì )因疏忽而成功，因為 Assert 仍然在發(fā)揮作用。您應該將此代碼放在私有函數中，這樣，Assert 就會(huì )自動(dòng)在方法返回之后從堆棧中刪除（使用 RevertAssert 調用）。使此方法私有非常重要，這樣攻擊者就無(wú)法使用外部代碼來(lái)調用該方法。
考慮下面的示例。
Private void PrivilegedOperation() { // Demand for permission. new FileIOPermission( PermissionState.Unrestricted ).Demand(); // Assert to allow caller with insufficient permissions. new FileIOPermission( PermissionState.Unrestricted ).Assert(); // Perform your privileged operation. }
在默認的情況下，完全受信任的程序集并不允許從部分受信任的應用程序或程序集中進(jìn)行調用；這樣的調用會(huì )引起安全異常。為了避免這些異常，可以將 AllowPartiallyTrustedCallersAttribute (APTCA) 添加到 Visual Studio .NET 生成的 AssemblyInfo.cs 文件中，如下所示。
[assembly: AllowPartiallyTrustedCallersAttribute()]
注應該對使用 APTCA 的代碼進(jìn)行評審，以確保它不會(huì )被任何部分受信任的惡意代碼所利用。有關(guān)詳細信息，請參閱 Improving Web Application Security: Threats and Countermeasures 的“Chapter 8 — Code Access Security in Practice”中的“APTCA”，地址在
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp。
考慮使用強名稱(chēng)的程序集
使用強名稱(chēng)可以提高程序集的安全性。您應該考慮使用強名稱(chēng)來(lái)簽署您的應用程序中的所有程序集，并且修改安全策略以信任此強名稱(chēng)。您可以使用 Sn.exe 工具簽署帶有強名稱(chēng)密鑰對的程序集。要手動(dòng)更改安全策略，可以使用 .NET Framework Configuration MMC 管理單元或 Caspol.exe，一個(gè)命令行工具（位于 %SystemRoot%\Microsoft.NET\Framework\< version>\CasPol.exe）。
使用私鑰簽署程序集的過(guò)程應該進(jìn)行如下考慮：
?
將延遲簽署用于開(kāi)發(fā)。編譯代碼的編譯過(guò)程可以使用延遲簽署，從而使用強名稱(chēng)密鑰對的公共部分而不是私鑰。要使用延遲簽署，開(kāi)發(fā)人員可以將下面的屬性添加到項目的 Assembly.cs 文件中。
[assembly:AssemblyKeyFile("publickey.snk")] [assembly:AssemblyDelaySign(true)]
?
保護生成的私鑰。下面的命令行展示了強名稱(chēng)工具 (Sn.exe) 的使用，該工具是 .NET Framework SDK 附帶的，用于生成直接針對可移動(dòng)存儲設備的密鑰對 (Keypair.snk)。（在本例中，使用的 F 驅動(dòng)器是 USB 驅動(dòng)器）
sn -k f:\keypair.snk sn -p f:\keypair.snk f:\publickey.snk
公鑰 (Publickey.snk) 用于開(kāi)發(fā)人員進(jìn)行延遲簽署。該密鑰對存儲在具有高度受限的訪(fǎng)問(wèn)權限的安全位置。
?
禁用對測試的驗證。要測試已經(jīng)延遲簽署的程序集，可以使用 Sn.exe 在測試計算機上注冊它。表 5.1 列出了常用的命令行變體。
表 5.1 常用的命令行變體
命令 描述
sn -Vr assembly.dll
禁用對特定程序集的驗證。
sn -Vr *,publickeytoken
禁用對具有特定公鑰的所有程序集的驗證。星號 (*) 通過(guò)對應于為忽略驗證提供的公鑰令牌的密鑰來(lái)注冊所有延遲簽署的程序集。
?
通過(guò)供發(fā)布的私鑰進(jìn)行簽署。要完成簽署過(guò)程，可以使用下面的命令通過(guò)私鑰進(jìn)行簽署。
sn -r assembly.dll f:\keypair.snk
在簽署程序集以供在組織中使用之前，指定的組成員應該對其進(jìn)行測試和評審。
有關(guān)延遲簽署和本節中解釋的過(guò)程的詳細信息，請參閱 Improving Web Application Security: Threats and Countermeasures 中的下列資源：
?
http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh03.asp 上的“Chapter 3 — Threat Modeling”。
?
http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh07.asp 上的“Chapter 7 — Building Secure Assemblies”中的“Delay Signing”。
?
http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh05.asp 上的“Chapter 5 — Architecture and Design Review for Security”。
?
http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh21.asp 上的“Chapter 21 — Code Review”。
同時(shí)參閱下列資源：
?
http://www.dotnetthis.com/Articles/SNandSmartCards.htm 上的“Strong Name Signing Using Smart Cards in Enterprise Software Production Environment”。
避免給受限區域賦予完全的信任
作為解決部分受信任的應用程序的安全問(wèn)題的一個(gè)快速替代解決方案，您可能非常想給受限區域（例如 Internet 或本地 Intranet 區域）賦予完全的信任。這樣做會(huì )允許任何應用程序在沒(méi)有進(jìn)行代碼訪(fǎng)問(wèn)安全檢查的情況下就運行在本地系統上，如果應用程序來(lái)自惡意的來(lái)源，這就成為一個(gè)問(wèn)題。然而，如果在設計階段考慮部署方案，就不必開(kāi)放安全性來(lái)允許應用程序運行。
設計完全受信任的應用程序
因為部分受信任的應用程序可能對系統資源具有非常少的權限，所以為了正確地運行，應用程序可能需要比默認分配給它的權限更多的權限。需要能夠執行諸如啟動(dòng) Office 應用程序或 Microsoft Internet Explorer、調用舊式 COM 組件、寫(xiě)入文件系統這樣的任務(wù)的應用程序必須具有顯式啟用這些操作的權限才能運行。
將應用程序指定為完全受信任的應用程序，這樣就可以給它分配所有可能的權限，這對我們是很有吸引力的。然而，更安全的做法是，在設計和部署應用程序時(shí)，只要求應用程序正確運行所需的最小權限。如果您確實(shí)需要將應用程序作為完全受信任的應用程序來(lái)運行，就必須考慮使用下列指導原則：
?
確定程序集需要訪(fǎng)問(wèn)的資源的類(lèi)型，評估在程序集受到損害時(shí)可能發(fā)生的潛在威脅。
?
確定目標環(huán)境的信任級別，因為代碼訪(fǎng)問(wèn)安全策略可能對程序集的功能進(jìn)行限制。
?
使用只用于構成程序集公共接口的一部分的類(lèi)和成員的公共訪(fǎng)問(wèn)修飾符來(lái)減少攻擊面。只要有可能，就使用 private 或 protected 訪(fǎng)問(wèn)修飾符來(lái)限制對所有其他類(lèi)和成員的訪(fǎng)問(wèn)。
?
使用 sealed 關(guān)鍵字來(lái)防止對沒(méi)有設計為基類(lèi)的類(lèi)的繼承，如下面的代碼所示。
public sealed class NobodyDerivesFromMe {...}
?
只要有可能，就使用聲明性類(lèi)級別或方法級別屬性來(lái)限制對指定的 Windows 組的成員的訪(fǎng)問(wèn)，如下面的代碼所示。
[PrincipalPermission(SecurityAction.Demand,Role=@"DomainName\WindowsGroup")] public sealed class Orders() {...}
?
為延遲簽署、測試、安全評審和保護私鑰建立安全構建過(guò)程。
返回頁(yè)首小結
智能客戶(hù)端應用程序在本質(zhì)上是分布式的，因此，為了有效地管理它們的安全性，需要考慮服務(wù)器上的安全、客戶(hù)端上的安全、以及兩者之間的網(wǎng)絡(luò )連接的安全。具體的智能客戶(hù)端考慮事項包括設計安全身份驗證、授權、數據驗證和保護敏感數據。您還應該研究如何使用代碼訪(fǎng)問(wèn)安全機制來(lái)管理代碼級而不是用戶(hù)級的安全性。
