WPF 安全性策略 – 平台安全性

儘管 Windows Presentation Foundation (WPF) 提供各種安全性服務，但其還會利用底層平台 (包括作業系統、CLR 和 Internet Explorer) 的安全性功能。 這些層級一起為 WPF 提供了強大、深入防禦的安全性模型，嘗試避免任何單一失敗點，如下圖所示：

此圖顯示 WPF 安全性模型。

此主題的其餘部分會針對這其中每一層，與 WPF 特別相關的功能進行討論。

作業系統安全性

Windows 的核心提供數個安全性功能，以形成所有 Windows 應用程式 (包括以 WPF 建置的應用程式) 的安全性基礎。 此主題會詳細討論這些對 WPF 至關重要的安全性功能，以及 WPF 如何整合這些功能來提供進一步的深入防禦。

Microsoft Windows XP Service Pack 2 (SP2)

除了對 Windows 進行整體回顧並加強觀念之外，此主題還將討論 Windows XP SP2 的三個主要功能：

• /GS 編譯

• Microsoft Windows Update。

/GS 編譯

Windows XP SP2 透過重新編譯許多核心系統程式庫 (包括 CLR 等所有 WPF 相依性) 來提供保護，以協助減少發生緩衝區滿溢的情況。 搭配 C/C++ 命令列編譯器使用 /GS 參數即可達成這個目的。 雖然這樣做應該能夠明確避免發生緩衝區滿溢的情況，但是 /GS 編譯還提供一個深入防禦範例，可防止無意中或惡意利用緩衝區滿溢所造成的潛在弱點遭到攻擊。

在過去，緩衝區滿溢一直是造成許多重大安全性攻擊的原因。 當攻擊者利用程式碼弱點，插入將緩衝區寫爆的惡意程式碼時，就會發生緩衝區滿溢的情況。 這會讓攻擊者有機會透過覆寫函式的傳回位址，來劫持執行該程式碼的處理序，以執行攻擊者的程式碼。 結果是，惡意程式碼可以利用與被劫持的處理序相同的權限來執行任意程式碼。

整體而言，-GS 編譯器旗標會針對具有本機字串緩衝區的函式，插入特殊的安全性 Cookie 來保護其傳回位址，因而可防止發生一些可能的緩衝區滿溢情況。 在函式傳回之後，安全性 Cookie 會與其原先的值做比較。 如果這個值已變更，則可能發生緩衝區滿溢的情況，而且會停止處理序並顯示錯誤狀況。 停止處理序可防止執行可能惡意的程式碼。 如需詳細資訊，請參閱 -GS (緩衝區安全性檢查) (部分機器翻譯)。

WPF 會利用 /GS 旗標進行編譯，為 WPF 應用程式提供多一層的防禦。

Windows Vista

Windows Vista 上的 WPF 使用者將從作業系統額外提供的安全性增強功能中獲益，包括「最低權限使用者存取」、程式碼完整性檢查和權限隔離。

使用者帳戶控制 (UAC)

今日的 Windows 使用者通常會以系統管理員權限執行，因為有許多應用程式需要這些權限，才能進行安裝和 (或) 執行。 其中一個例子是，使用者必須能夠將預設應用程式設定寫入至登錄。

以系統管理員權限執行，實際上表示應用程式會從具有系統管理員權限的處理序執行。 這樣做會有安全性風險，那就是劫持以系統管理員權限執行之處理序的任何惡意程式碼，都會自動繼承這些權限，包括重要系統資源的存取權。

防範這個安全性威脅的方法之一，就是以最少的必要權限執行應用程式。 這就是所謂的最低權限原則，是 Windows 作業系統的核心功能。 此功能稱為使用者帳戶控制 (UAC)，Windows UAC 會透過兩種主要方式加以使用：

• 讓大多數的應用程式預設以 UAC 權限執行，即使使用者是系統管理員也一樣。只有需要系統管理員權限的應用程式才會以系統管理員權限執行。 若要以系統管理員權限執行，應用程式必須在其應用程式資訊清單中明確標記，或明確標記為安全性原則中的項目。

• 提供像是虛擬化的相容性解決方案。 例如，許多應用程式會嘗試寫入限制位置，例如 C:\Program Files。 如果應用程式是以 UAC 執行，則會建立依使用者而定的替代位置，應用程式不需要有系統管理員權限就能寫入至這個位置。 如果應用程式是以 UAC 執行，則 UAC 會將 C:\Program Files 虛擬化，讓以為寫入至這個位置的應用程式，實際上是寫入至依使用者而定的替代位置。 這種相容性轉換工作可讓作業系統執行更多應用程式 (之前在 UAC 中執行時，並無法執行這麼多應用程式)。

程式碼完整性檢查

Windows Vista 併入了更深入的程式碼完整性檢查，以協助防止在載入/執行階段，將惡意程式插入至系統檔案或核心中。 這已經超過系統檔案保護範圍。

瀏覽器裝載之應用程式的有限權限處理序

瀏覽器裝載的 WPF 應用程式會在網際網路區域沙箱中執行。 WPF 與 Microsoft Internet Explorer 的整合，可透過額外支援來擴大此保護。

由於 XAML 瀏覽器應用程式 (XBAP) 通常會以網際網路區域權限集合進行沙箱化，因此，從相容性觀點來看，移除這些權限不會毀損 XAML 瀏覽器應用程式 (XBAP)。 反而可以建立多一層的深層防禦。即使沙箱化的應用程式能夠攻擊其他層級並劫持處理序，處理序仍然只會有有限的權限。

請參閱 Using a Least-Privileged User Account (使用最低權限使用者帳戶)。

Common Language Runtime 安全性

通用語言執行平台 (CLR) 提供一些重要的安全性優點，包括驗證 (Validation) 和驗證 (Verification)、程式碼存取安全性 (CAS) 和安全性關鍵方法。

驗證 (Validation 和 Verification)

為提供組件隔離和完整性，CLR 會使用驗證流程。 CLR 驗證會透過針對指向組件外部的位址驗證其可攜式執行檔 (PE) 檔案格式來確保組件已隔離。 CLR 驗證也會驗證組件中內嵌之中繼資料的完整性。

為確保型別安全、協助防止常見的安全性問題 (例如緩衝區滿溢)，以及透過子處理序隔離啟用沙箱化，CLR 安全性會使用驗證的概念。

Managed 應用程式會編譯成 Microsoft 中繼語言 (MSIL)。 執行 Managed 應用程式中的方法時，應用程式的 MSIL 會透過 Just-In-Time (JIT) 編譯被編譯成機器碼。 JIT 編譯包含驗證程序，這個程序會套用許多安全和穩定性規則，以確保程式碼不會：

• 違反類型合約

• 引入緩衝區滿溢

• 大量存取記憶體

不符合驗證規則的 Managed 程式碼除非受到信任，否則無法執行。

可驗證程式碼的優點是在 .NET Framework 上建置 WPF 的主要原因。 只要是使用可驗證程式碼的地方，潛在弱點遭受攻擊的可能性都會大幅降低。

程式碼存取安全性

用戶端電腦公開了可供 Managed 應用程式存取的各種資源，包括檔案系統、登錄、列印服務、使用者介面、反映和環境變數。 受管理應用程式必須具有 .NET Framework 權限，才能存取用戶端電腦上的任何資源。 CAS 中的權限是 CodeAccessPermission (英文) 的子類別；CAS 會針對受管理應用程式可存取的每個資源各實作一個子類別。

當受管理應用程式開始執行時，CAS 會授與應用程式一組權限，稱為權限集合，並由應用程式提供的辨識項來決定。 針對 WPF 應用程式，提供的辨識項就是應用程式啟動的位置 (或區域)。 CAS 會識別下列區域：

• 我的電腦。 從用戶端電腦啟動的應用程式 (完全信任)。

• 近端內部網路。 從內部網路啟動的應用程式 (部分受信任)。

• 網際網路。 從網際網路啟動的應用程式 (最不受信任)。

• 信任的網站。 使用者指定要信任的應用程式 (最不受信任)。

• 限制的網站。 使用者指定不要信任的應用程式 (未受信任)。

針對這其中每個區域，CAS 會提供一個預先定義的權限集合，其中包含與每個區域相關聯之信任層級相符的權限。 包括：

• FullTrust。 適用於從 [我的電腦] 區域啟動的應用程式。 會授與所有可能的權限。

• LocalIntranet。 適用於從 [近端內部網路] 區域啟動的應用程式。 會授與權限的子集，以提供對用戶端電腦資源的中度存取權，包括隔離儲存區、無限制的 UI 存取權、無限制的檔案對話方塊、有限的反映、對環境變數的有限存取權。 不會提供重要資源 (例如登錄) 的權限。

• 網際網路。 適用於從 [網際網路] 或 [信任的網站] 區域啟動的應用程式。 會授與權限的子集，以提供對用戶端電腦資源的有限存取權，包括隔離儲存區、限檔案開啟，以及有限的 UI。 基本上，此權限集合會將應用程式與用戶端電腦隔離。

CAS 絕對不會將任何權限授與識別為來自 [限制的網站] 區域的應用程式。 因此，這些應用程式沒有預先定義的權限集合。

下圖說明區域、權限集合、權限及資源之間的關聯性：

此圖顯示 CAS 權限集合。

網際網路區域安全性沙箱的限制同樣適用於 XBAP 從系統程式庫 (包括 WPF) 匯入的所有程式碼。 如此可確保程式碼的每個位元都會遭到鎖定，即使是 WPF 也一樣。 不幸的是，為了能夠執行，XBAP 必須執行的功能所需權限比網際網路區域安全性沙箱所啟用的還要多。

假設有個 XBAP 應用程式包含下列頁面：

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

若要執行此 XBAP，底層 WPF 程式碼必須執行比可用於呼叫 XBAP 還多的功能，包括：

• 建立轉譯用的視窗控制代碼 (HWND)

• 分派訊息

• 載入新細明體字型

從安全性觀點來看，允許沙箱化應用程式直接存取上述任何作業將會引發十分嚴重的後果。

好在 WPF 已經考慮到這種情況，允許這些作業代表沙箱化應用程式以較高的權限執行。 雖然所有 WPF 作業都會針對 XBAP 應用程式定義域的有限網際網路區域安全性權限進行檢查，但是 WPF (與其他系統程式庫一樣) 會獲授與含有所有可用權限的權限集合。

這要求 WPF 接收較高的權限，同時防止那些權限受到主應用程式定義域的網際網路區域權限集合所控管。

WPF 會透過使用權限的 Assert 方法來執行此動作。 下列程式碼會顯示這個過程。

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()

' Perform operation that uses the assert

' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()

Assert 基本上會防止 WPF 所需的無限制權限受到 XBAP 之網際網路區域權限的限制。

從平台觀點來看，WPF 負責正確使用 Assert；不正確地使用 Assert 可能會讓惡意程式碼提高權限。 因此，請務必只有在必要時才呼叫 Assert，並確保沙箱限制保持不變。 例如，沙箱化程式碼不可以開啟隨機檔案，但可以使用字型。 WPF 會透過呼叫 Assert，允許沙箱化應用程式使用字型功能，並且讓 WPF 代表沙箱化應用程式讀取已知含有那些字型的檔案。

ClickOnce 部署

ClickOnce 是 .NET Framework 隨附的完整部署技術，且已與 Visual Studio 整合 (如需詳細資訊，請參閱 ClickOnce 安全性和部署)。 獨立 WPF 應用程式可以使用 ClickOnce 部署，而瀏覽器裝載的應用程式必須透過 ClickOnce 部署。

使用 ClickOnce 部署的應用程式會透過程式碼存取安全性 (CAS) 多獲得一層安全性；基本上，ClickOnce 部署的應用程式會要求其所需的權限。 只有在所要求的權限不超過應用程式部署來源區域的權限集合時，才會將這些權限授與應用程式。 藉由將權限集合減少到只含所需的權限，即使其比啟動區域權限集合所提供的權限還少，應用程式有權存取的資源數量也會降到最基本的數量。 因此，如果應用程式遭到劫持，用戶端電腦遭到破壞的可能性將會降低。

安全性關鍵方法

使用權限來對 XBAP 應用程式啟用網際網路區域沙箱的 WPF 程式碼，必須遵守最高可能的安全性稽核和控制程度。 為了滿足此需求，.NET Framework 提供新支援來管理提高權限的程式碼。 具體來說，CLR 可讓您識別提高權限的程式碼，並以 SecurityCriticalAttribute (部分機器翻譯) 標記；使用此方法，所有未以 SecurityCriticalAttribute (部分機器翻譯) 標記的程式碼都會變成「透明」。 相反地，未標記為 SecurityCriticalAttribute 的 Managed 程式碼將無法提高權限。

安全性關鍵方法可讓您將提高權限的 WPF 程式碼組織為「安全性關鍵核心」，同時將其餘程式碼當作透明。 隔離安全性關鍵程式碼，可讓 WPF 工程團隊專心以超越標準的安全性做法，對安全性關鍵核心進行額外的安全性分析和原始檔控制 (請參閱 WPF 安全性策略 - 安全性工程)。

請注意，.NET Framework 允許利用信任的程式碼來擴充 XBAP 網際網路區域沙箱，方式是允許開發人員撰寫已使用 AllowPartiallyTrustedCallersAttribute (APTCA) (部分機器翻譯) 標記的受控組件，然後部署至使用者的全域組件快取 (GAC)。 在組件上標記 APTCA 是一項極為敏感的安全性作業，因為這可讓任何程式碼 (包括來自網際網路的惡意程式碼) 呼叫該組件。 執行這項操作時請謹慎為之，一定要採取最佳做法，而且使用者必須選擇信任該軟體才能安裝軟體。

Microsoft Internet Explorer 安全性

除了減少安全性問題和簡化安全性設定之外，Microsoft Internet Explorer 6 (SP2) 還包含數個安全性增強功能，可增強 XAML 瀏覽器應用程式 (XBAP) 使用者的安全性。 這些功能的主要目的是要讓使用者更能掌控自己的瀏覽體驗。

在 IE6 SP2 之前，使用者可能受限於下列任一種情況：

• 隨機跳出的快顯視窗。

• 令人困惑的指令碼重新導向。

• 某些網站上的大量安全性對話方塊。

在某些情況下，不可信賴的網站會嘗試冒充安裝使用者介面 (UI) 或一再顯示 Microsoft ActiveX 安裝對話方塊 (即便使用者取消也一樣) 來誘騙使用者。 透過這些手法，許多使用者可能信以為真，做出錯誤決定，因而安裝了間諜軟體應用程式。

IE6 SP2 以使用者啟始的概念為核心，提供數個可減少這類問題的功能。 IE6 SP2 會偵測使用者在某個動作之前按下連結或頁面元素的時機 (稱為「使用者啟始」)，並將其視為與在改為由頁面上指令碼觸發類似動作時不同。 例如，IE6 SP2 包含快顯封鎖程式，其會偵測使用者在頁面建立快顯之前按下按鈕的時機。 這讓 IE6 SP2 允許顯示大多數無害的快顯視窗，同時又能封鎖使用者未要求或不想要的快顯視窗。 遭封鎖的快顯視窗會由新的資訊列擋住，而使用者可以手動取消封鎖來檢視該快顯視窗。

相同的使用者啟始邏輯也適用於開啟/儲存安全性提示。 除非 ActiveX 代表從先前安裝之控制項的升級，否則其安裝對話方塊一律會遭到 [資訊列] 截獲。 這些措施一起為使用者提供了更安全、更受控制的使用者經驗，因為使用者將可擺脫陌生網站為了讓使用者安裝不必要或惡意的軟體，而一再進行的騷擾。

這些功能也會保護使用 IE6 SP2 瀏覽可下載並安裝 WPF 應用程式之網站的客戶。 具體而言，這是因為不論惡意或狡詐的應用程式是以何種技術建置 (包括 WPF)，IE6 SP2 都能減少使用者安裝這類應用程式的機會，進而改善使用者體驗。 WPF 可藉由使用 ClickOnce，透過網際網路加速下載應用程式，從而增加這些保護。 由於 XAML 瀏覽器應用程式 (XBAP) 會在網際網路區域安全性沙箱中執行，因此可順暢啟動。 另一方面，獨立 WPF 應用程式需要完全信任才能執行。 對於這些應用程式，ClickOnce 將會在啟動過程中顯示安全性對話方塊，以通知有關應用程式其他安全性需求的使用。 不過，這必須由使用者啟始、同時受到使用者啟始的邏輯控制，並且可以取消。

Internet Explorer 7 併入並擴充了 IE6 SP2 的安全性功能，作為持續提供安全性承諾的一部分。

另請參閱

• 程式碼存取安全性
• 安全性
• WPF 部分信任安全性
• WPF 安全性策略 – 安全性工程