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

  • 發行項

雖然 Windows Presentation Foundation （WPF） 提供各種安全性服務，但它也會利用基礎平台的安全性功能，包括操作系統、CLR 和 Internet Explorer。 這些層級結合以提供強式的深度防禦安全性模型，以嘗試避免任何單一失敗點，如下圖所示：

Diagram that shows the WPF security model.

本主題的其餘部分將討論與 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 整合可透過其他支援來擴充此保護。

警告

XBAP 需要舊版瀏覽器才能運作，例如 Internet Explorer 和 Firefox。 Windows 10 和 Windows 11 通常不支援這些舊版瀏覽器版本。 由於安全性風險，新式瀏覽器不再支援 XBAP 應用程式所需的技術。 不再支援啟用 XBAP 的外掛程式。

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

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

Common Language Runtime 安全性

Common Language Runtime （CLR） 提供一些重要的安全性優點，包括驗證和驗證、程式代碼存取安全性（CAS），以及安全性關鍵方法。

驗證 (Validation 和 Verification)

為了提供元件隔離和完整性，CLR 會使用驗證程式。 CLR 驗證可確保元件會藉由驗證其可攜式可執行檔 （PE） 檔案格式來隔離元件，而該位址位於元件外部。 CLR 驗證也會驗證內嵌在元件內的元數據完整性。

為了確保類型安全性，協助防止常見的安全性問題（例如緩衝區滿溢），並透過子進程隔離啟用沙盒化，CLR 安全性會使用驗證的概念。

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

  • 違反類型合約

  • 引入緩衝區滿溢

  • 大量存取記憶體

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

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

程式碼存取安全性

用戶端電腦公開了可供 Managed 應用程式存取的各種資源，包括檔案系統、登錄、列印服務、使用者介面、反映和環境變數。 在受控應用程式可以存取用戶端電腦上的任何資源之前，它必須具有 .NET Framework 許可權才能執行此動作。 CAS 中的許可權是 的子類別; CodeAccessPermissionCAS 會針對受控應用程式可以存取的每個資源實作一個子類別。

CAS 在開始執行時授與受控應用程式的許可權集合稱為許可權集合，並由應用程式所提供的辨識項決定。 針對 WPF 應用程式，所提供的辨識項是啟動應用程式的位置或區域。 CAS 會識別下列區域：

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

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

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

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

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

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

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

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

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

識別為來自 未受信任網站 區域的應用程式完全不會獲得 CAS 的許可權。 因此，這些應用程式沒有預先定義的權限集合。

下圖說明區域、許可權集合、許可權和資源之間的關聯性：

Diagram that shows CAS permission sets.

因特網區域安全性沙盒的限制同樣適用於 XBAP 從系統連結庫匯入的任何程式代碼，包括 WPF。 這可確保程式代碼的每個位都會鎖定，甚至是 WPF。 不幸的是，為了能夠執行，XBAP 必須執行比因特網區域安全性沙箱啟用的許可權更多的功能。

警告

XBAP 需要舊版瀏覽器才能運作，例如 Internet Explorer 和 Firefox。 Windows 10 和 Windows 11 通常不支援這些舊版瀏覽器版本。 由於安全性風險，新式瀏覽器不再支援 XBAP 應用程式所需的技術。 不再支援啟用 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 程式碼將無法提高權限。

警告

XBAP 需要舊版瀏覽器才能運作，例如 Internet Explorer 和 Firefox。 Windows 10 和 Windows 11 通常不支援這些舊版瀏覽器版本。 由於安全性風險，新式瀏覽器不再支援 XBAP 應用程式所需的技術。 不再支援啟用 XBAP 的外掛程式。

安全性關鍵方法可讓 WPF 程式代碼的組織將許可權提升為 安全性關鍵核心，其餘部分則為透明。 隔離安全性關鍵程式代碼可讓 WPF 工程小組將額外的安全性分析和原始檔控制放在高於標準安全性做法的安全性關鍵核心上（請參閱 WPF 安全性策略 - 安全性工程）。

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

Microsoft Internet Explorer 安全性

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

警告

XBAP 需要舊版瀏覽器才能運作，例如 Internet Explorer 和 Firefox。 Windows 10 和 Windows 11 通常不支援這些舊版瀏覽器版本。 由於安全性風險，新式瀏覽器不再支援 XBAP 應用程式所需的技術。 不再支援啟用 XBAP 的外掛程式。

在 IE6 SP2 之前，使用者可以受限於下列任何一項：

  • 隨機跳出的快顯視窗。

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

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

在某些情況下，不受信任的網站會嘗試欺騙使用者，方法是詐騙安裝使用者介面 （UI） 或重複顯示 Microsoft ActiveX 安裝對話框，即使使用者可能已經取消它。 透過這些手法，許多使用者可能信以為真，做出錯誤決定，因而安裝了間諜軟體應用程式。

IE6 SP2 包含數個功能，可減輕這類問題，其圍繞使用者起始的概念。 IE6 SP2 會在動作之前按兩下連結或頁面元素時偵測到該動作，這稱為 使用者起始，並且會以不同於頁面上腳本所觸發的類似動作時處理它。 例如，IE6 SP2 會 納入快顯封鎖程式 ，可偵測使用者在建立快顯頁面前按兩下按鈕時。 這可讓 IE6 SP2 允許大多數無害的彈出視窗，同時防止使用者不要求或想要的彈出視窗。 遭封鎖的快顯視窗會由新的資訊列擋住，而使用者可以手動取消封鎖來檢視該快顯視窗。

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

這些功能也會保護使用 IE6 SP2 瀏覽至允許他們下載及安裝 WPF 應用程式的網站的客戶。 特別是，這是因為 IE6 SP2 提供更佳的用戶體驗，可減少使用者安裝惡意或狡猾的應用程式的機會，而不論使用何種技術來建置它，包括 WPF。 WPF 會使用 ClickOnce 新增至這些保護，以利透過因特網下載其應用程式。 由於 XAML 瀏覽器應用程式 （XBAP） 會在因特網區域安全性沙箱內執行，因此可以順暢地啟動它們。 另一方面，獨立 WPF 應用程式需要完全信任才能執行。 針對這些應用程式，ClickOnce 會在啟動程式期間顯示安全性對話方塊，以通知使用應用程式的其他安全性需求。 不過，這必須由使用者啟始、同時受到使用者啟始的邏輯控制，並且可以取消。

Internet Explorer 7 納入並擴充 IE6 SP2 的安全性功能，作為持續致力於安全性的一部分。

另請參閱