共用方式為


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

雖然 Windows Presentation Foundation (WPF) 本身提供了各項安全性服務,但是它也會利用基礎平台 (包括作業系統、CLR 和 Internet Explorer) 的安全性功能。 這三層安全性功能一起為 WPF 提供了強大、深入防禦的安全性模型,即使其中一層失敗,還有兩層可以幫忙把關,如下圖所示:

WPF 安全性圖例

本主題的其餘部分會針對每一層安全性功能當中,與 WPF 特別有關的功能進行討論。

這個主題包含下列章節。

  • 作業系統安全性
  • Common Language Runtime 安全性
  • Microsoft Internet Explorer 安全性
  • 相關主題

作業系統安全性

WPF 需要的最低作業系統層級是 Windows XP SP2。 Windows XP SP2 的核心提供數項安全性功能,這些安全性功能是所有 Windows 應用程式 (包括以 WPF 建置的應用程式) 的安全性基礎。 Windows Vista 加入了 WPF 的安全性功能,並做進一步擴充。 本主題會詳細討論這些對 WPF 至為重要的安全性功能,以及 WPF 如何整合這些功能來提供進一步的深入防禦。

Microsoft Windows XP Service Pack 2 (SP2)

除了對 Windows 的一般概述和觀念加強之外,本主題中還會討論 Windows XP SP2 的三項主要功能:

  • /GS 編譯

  • Microsoft Windows Update

/GS 編譯

Windows XP SP2 可提供下列保護:重新編譯許多核心系統程式庫 (包括所有 CLR 這類的 WPF 相依性) 來降低緩衝區滿溢 (Buffer Overrun) 的機會。 這是透過 C/C++ 命令列編譯器 (Compiler) 並搭配 /GS 參數來達成。 雖然應該明確地避免緩衝區滿溢,但是 /GS 編譯提供了一個深入防禦的範例,來防範無意中或惡意利用緩衝區滿溢建立的弱點。

在過去,緩衝區滿溢是許多重大安全性攻擊的主因。 緩衝區滿溢的出現,肇因於攻擊者利用程式碼弱點,插入將緩衝區寫爆的惡意程式碼。 然後攻擊者便可以劫持執行該惡意程式碼的處理序,方法是覆寫函式的傳回位址來執行他自己的程式碼。 結果是,惡意程式碼可以利用被劫持處理序的相同權限來執行任意程式碼。

整體而言,/GS 編譯器旗標可以防範部分可能的緩衝區滿溢,方法是針對具有本機字串緩衝區的函式,插入一種特殊的安全性 Cookie 來保護該函式的傳回位址。 在函式進行傳回後,安全性 Cookie 會與其原先的值做比較。 如果這個值改變了,即表示可能發生緩衝區滿溢的情況,而處理序會停止並顯示錯誤狀況。 使處理序停止,可以防止執行任何可能的惡意程式碼。 如需詳細資訊,請參閱 /GS (緩衝區安全性檢查)

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

Microsoft Windows Update 增強功能

Windows XP SP2 也將 Microsoft Windows Update 做了改善,下載和安裝更新的程序將會更簡單。 由於這些變更 (特別是安全性更新方面) 可協助確保 WPF 客戶的系統會更新成最新版本,因此可以大幅提高這些客戶的安全性。

Windows Vista

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

使用者帳戶控制 (UAC)

今日的 Windows 使用者經常會使用具有系統管理員權限的執行身分,因為有許多應用程式要求他們進行安裝或執行 (或兩個都有) 的動作。 其中一個例子是,使用者必須能夠將預設應用程式設定寫入至登錄。

使用具有系統管理員權限的執行身分時,應用程式實際上會從擁有系統管理員權限的處理序執行。 這樣有個安全性風險,就是倘若惡意程式碼劫持了以系統管理員權限執行的處理序,該惡意程式碼就會自動繼承這些權限,包括對重要系統資源的存取權。

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

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

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

程式碼完整性檢查

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

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

瀏覽器裝載的 WPF 應用程式是在 [網際網路] 區域沙箱中執行。 WPF 與 Microsoft Internet Explorer 的整合,使這項保護得到更多支援。

Internet Explorer 6 Service Pack 2 和 Internet Explorer 7 for XP

WPF 利用作業系統安全性,方法是限制 XAML browser applications (XBAPs) 的處理序權限以提供進一步的保護。 在啟動瀏覽器裝載的 WPF 應用程式之前,作業系統會先建立主機處理序,這個處理序會從處理序權杖中移除不必要的權限。 所移除的一些權限範例包括關閉使用者電腦的能力、載入驅動程式的能力,以及電腦上所有檔案的讀取存取權。

Internet Explorer 7 for Vista

在 Windows Internet Explorer 7 中,WPF 應用程式是以受保護模式執行。 具體來說,XAML browser applications (XBAPs) 是以中度完整性執行。

深層防禦

由於 XAML browser applications (XBAPs) 通常會以 [網際網路] 區域權限集合進行沙箱化 (Sandboxed),所以移除這些權限不但不會破壞 XAML browser applications (XBAPs) 的相容性, 反而可以建立多一層的深層防禦。如果被沙箱化的應用程式能夠攻擊其他層並劫持處理序,處理序仍然只會有有限的權限。

請參閱使用最低權限使用者帳戶 (英文)。

Common Language Runtime 安全性

common language runtime (CLR) 提供若干重要安全性優點,包括驗證 (Validation) 和驗證 (Verification)、Code Access Security (CAS),以及重要安全性方法。

驗證 (Validation) 和驗證 (Verification)

CLR 使用驗證程序提供組件隔離和完整性。 CLR 驗證 (Validation) 會驗證組件的 PE 檔案格式中是否有指向組件外部的位址,藉此確實隔離組件。 CLR 驗證也會驗證組件中內嵌中繼資料 (Metadata) 的完整性。

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

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

  • 違反型別合約

  • 造成緩衝區滿溢

  • 大量存取記憶體

不符合驗證 (Verification) 規則的 Managed 程式碼必須被視為信任的程式碼,否則無法執行。

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

程式碼存取安全性

用戶端機器公開了可供 Managed 應用程式存取的各種資源,包括檔案系統、登錄、列印服務、使用者介面、反映 (Reflection) 和環境變數。 Managed 應用程式在存取用戶端機器上的任何資源之前,必須先具備適當的 .NET Framework Code Access Security (CAS) 權限。 CAS 中的權限其實是 CodeAccessPermission 的子類別 (Subclass)。CAS 會針對 Managed 應用程式可以存取的每個資源各實作一個子類別。

CAS 在 Managed 應用程式啟動時授與此應用程式的一組權限統稱為權限集合,而這個權限集合是依應用程式提供的辨識項來決定。 如果是 WPF 應用程式,則提供的辨識項就是應用程式啟動的位置 (或區域)。 CAS 可識別下列區域:

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

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

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

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

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

CAS 會針對上述每個區域各提供一個預先定義的權限集合,而每個權限集合都包含符合其區域信任層級的權限。 這些需求包括:

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

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

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

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

下圖說明區域、權限集合、權限和資源間的關係。

CAS 使用權限集合

[網際網路] 區域安全性沙箱的限制會平等套用至 XBAP 從系統程式庫 (包括 WPF) 匯入的所有程式碼。 這可確保程式碼的每個位元都被鎖定,即使是 WPF 也一樣。 不幸的是,XBAP 若要能夠執行,其須執行之功能所需要的權限比 [網際網路] 區域安全性沙箱所啟用的還要多。

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

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

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()
FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

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

若要執行這個 XBAP,基礎 WPF 程式碼需要執行的功能比發出呼叫的 XBAP 可以取得的功能還多,而需要執行的功能包括:

  • 建立轉譯用的視窗控制代碼 (Window Handle) (hWnd)

  • 分派訊息

  • 載入 Tahoma 字型

從安全性觀點來看,讓受到沙箱化的應用程式存取上述任一作業將會引發十分嚴重的後果。

幸運的是,WPF 已經考慮到這種情況,它會允許這些作業代表受到沙箱化的應用程式以更高的權限執行。 雖然所有的 WPF 作業都會被檢查是否符合 XBAP 之應用程式定義域的有限 [網際網路] 區域安全性權限,但是 WPF (就像其他系統程式庫) 卻會得到含有所有可用權限的權限集合。

這表示 WPF 必須得到更高的權限,同時又要避免這些權限受到主應用程式定義域之 [網際網路] 區域權限集合的控制。

WPF 是透過權限的 Assert 方法達到這個目的。 下列程式碼會顯示這個過程。

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

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()
FileIOPermission fp = 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 提供的完整部署技術,並且已與 Microsoft Visual Studio 整合 (如需詳細資訊請參閱 ClickOnce 部署概觀 (英文))。 獨立 WPF 應用程式可以透過 ClickOnce 部署,而瀏覽器裝載的應用程式則必須透過 ClickOnce 部署。

透過 ClickOnce 部署的應用程式會得到Code Access Security (CAS) 所提供的多一層安全性保障。基本上,由 ClickOnce 部署的應用程式會要求它們需要的權限。 但是只有在所要求的權限不超過應用程式部署來源區域的權限集合,它們才會得到這些權限。 藉由將權限集合減少到只含需要的權限,應用程式可以存取的資源將會降到最基本的數量,即使這些權限比啟動區域的權限集合所提供的權限還少也沒關係。 因此,萬一應用程式遭到劫持,用戶端機器遭到破壞的可能性將會降低。

重要安全性方法

使用權限來對 XBAP 應用程式啟用 [網際網路] 區域沙箱的 WPF 程式碼,其保存必須受到最高度的安全性稽核和控制。 為了滿足這個需求,.NET Framework 提供新的支援來管理需要得到更高權限的程式碼。 具體來說,CLR 可讓您識別要得到更高權限的程式碼,並以 SecurityCriticalAttribute 標示它。而根據這個方法,所有沒有標示 SecurityCriticalAttribute 的程式碼都會變成「透明」程式碼。 相反地,沒有標示 SecurityCriticalAttribute 的 Managed 程式碼將無法得到更高的權限。

「重要安全性方法」可讓您將需要得到更高權限的 WPF 程式碼組織到「重要安全性核心」中,同時將其餘程式碼當做透明程式碼。 隔離重要安全性程式碼,可讓 WPF 工程團隊專心以超越標準的安全性做法,對重要安全性核心進行額外的安全性分析和原始檔控制 (請參閱 WPF 安全性策略 – 安全性工程)。

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

Microsoft Internet Explorer 安全性

除了減少安全性問題和簡化安全性設定之外,Microsoft Internet Explorer 6 (SP2) 還包含數項可增強 XAML browser applications (XBAPs) 使用者安全性的安全性增強功能。 這些介面的主要目的是要讓使用者更能掌控自己的瀏覽經驗。

在 IE6 SP2 之前,使用者會受到下列項目干擾:

  • 隨機跳出的快顯視窗

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

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

有時候,不可信賴的網站會假裝提供user interface (UI) 或一再顯示 Microsoft ActiveX 安裝對話方塊 (即使使用者加以取消也一樣) 來誘騙使用者按下它們的連結。 許多使用者信以為真,做出按下連結的錯誤決定,因而安裝了間諜軟體應用程式。

IE6 SP2 以使用者啟始的概念為核心,提供數項可減少這類問題的功能。 當使用者按下某個連結或頁面項目時,IE6 SP2 會偵測到這個動作,並將之與由頁面程式碼觸發的類似動作區別開來,藉此避免觸發動作 (稱為「使用者啟始」)。 例如,IE6 SP2 包含「快顯封鎖程式」,它可在使用者按下按鈕時,偵測到這個動作並避免頁面建立外顯視窗。 這讓 IE6 SP2 能夠允許顯示無害的快顯視窗,同時又能封鎖使用者未要求或不想要的快顯視窗。 遭封鎖的快顯視窗會由新的「資訊列」擋住,而使用者可以手動取消封鎖來檢視該快顯視窗。

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

這些功能也會保護使用 IE6 SP2 來瀏覽可下載和安裝 WPF 應用程式之網站的客戶。 具體而言,這是因為不論惡意或詐欺的應用程式是以何種技術建置 (包括 WPF),IE6 SP2 都能減少使用者安裝這類應用程式的機會,進而改善使用者經驗。 此外,WPF 還可透過網際網路上的 ClickOnce 來下載應用程式,以將這些保護進行擴充。 由於 XAML browser applications (XBAPs) 會在 [網際網路] 區域安全性沙箱中執行,所以它們可以非常順利地執行。 另一方面,獨立的 WPF 應用程式則需要完全信任才能執行。 對於這些應用程式,ClickOnce 會在啟動程序期間顯示安全性對話方塊,以通知使用者必須遵守應用程式額外的安全性需求。 不過,這必須由使用者啟始、也由使用者啟始的邏輯所控制,而且可以取消。

Internet Explorer 7 加入並擴充了 IE6 SP2 中的安全性功能,以便繼續提供更好的安全性。

請參閱

概念

程式碼存取安全性

安全性 (WPF)

WPF 部分信任安全性

WPF 安全性策略 – 安全性工程

其他資源

了解 Windows XP SP2 的 Microsoft Internet Explorer 6 中的安全性

了解和使用 Internet Explorer 的保護模式

Windows XP Service Pack 3

Windows Vista 安全性指南