分享方式：

規劃步驟 4：規劃應用程式安全性

  • 文章

作者 ：Keith Newman 和 Robert McMurray

在建置您的網站的這個階段中，請考量您 ASP.NET 應用程式的安全性需求。 下列各節說明 IIS 8 中可用的應用程式安全性設定：

4.1. 隔離 Web 應用程式

其中一個改進 Web 應用程式安全性的最有效方法，就是將它與網頁伺服器上的其他應用程式隔離。 應用程式集區有自己的工作者處理序，用來處理要求和執行應用程式程式碼。 工作者處理序具有安全性識別碼 (SID)。 而每個應用程式集區都有一個唯一的應用程式集區身分識別。 根據預設，當您建立 Web 應用程式時，會一併建立一個與該應用程式同名的新應用程式集區。 如果您將 Web 應用程式存放在個別的應用程式集區中，就可以將它們彼此隔離。

Web 應用程式隔離需要下列各項：

  • 網站隔離：將不同的應用程式分別放在不同網站的不同應用程式集區中。
  • 最低權限：以每個站台唯一的低特殊權限身分識別 (虛擬應用程式集區身分識別) 執行工作者處理序。
  • 暫存隔離：為每個月臺設定個別 ASP.NET 暫存資料夾，並只提供適當進程身分識別的存取權。
  • 內容隔離：確定在每個站台根目錄上設定 ACL (存取控制清單)，以只允許存取適當的處理序身分識別 。

提示

建議您將網站和 Web 應用程式內容裝載在您系統磁碟機 (C:) 以外的磁碟機上。

4.2. .NET 信任層級

應用程式「信任層級」可決定 ASP.NET 程式碼存取安全性 (CAS) 原則授與的權限。 CAS 定義了兩種信任類別：完全信任和部分信任。 具有完全信任權限的應用程式可以存取伺服器上的所有資源類型，以及執行需要特殊權限的作業。 具有完全信任的應用程式只會受到作業系統的安全性設定影響。

部分信任的 Web 應用程式是指不具有完全信任且程式碼存取權限有限的應用程式。 因此，部分信任應用程式只能存取安全的資源，以及執行其他需要特殊權限的作業。 系統會拒絕將某些權限授與部分信任的應用程式，因此它們無法直接存取需要這些權限的資源。 其他權限皆是以受限的方式授與，因此它們可能可以存取需要這些權限的資源，但是會受到限制。 例如，受限制的檔案 IO 權限可讓應用程式存取檔案系統，但僅限於應用程式之虛擬目錄根目錄下的目錄。

您可以將 Web 應用程式或 Web 服務設定為僅具有部分信任，以限制應用程式只能存取重要的系統資源或屬於其他 Web 應用程式的資源。 您可以只授與應用程式所需的權限以建置僅具備最低特殊權限的 Web 應用程式，並限制當 Web 應用程式因遭到插入程式碼攻擊而洩漏時可能造成的損害。

下列清單會顯示每個信任層級的相關限制：

  • 完全信任應用程式可以不受限地存取所有資源類型，並且可以執行需要特殊權限的作業。
  • 高、中、低或最低信任度應用程式無法呼叫 Unmanaged 程式碼或服務元件、寫入事件記錄檔、存取「訊息佇列」佇列或存取 OLE DB 資料來源。
  • 高信任度應用程式可以不受限地存取檔案系統。
  • 中信任度應用程式具有受限制的檔案系統存取權，只能存取自己應用程式目錄階層中的檔案。
  • 低信任度或最低信任度應用程式無法存取 SQL Server 資料庫。
  • 最低信任應用程式無法存取任何資源。

4.3. .NET 驗證

驗證可協助您確認要求存取您的網站和應用程式之用戶端的身分識別。 啟用驗證時，IIS 8 會使用使用者所提供的帳號憑證來判斷使用者已授與的許可權，以及使用者可以存取哪些資源。

本節將說明 ASP.NET 應用程式特定的驗證模式。

  1. ASP.NET 表單驗證
  2. ASP.NET 模擬驗證

ASP.NET 表單驗證

表單驗證會使用用戶端重新導向，將未經驗證的使用者轉送至 HTML 表單，使用者可以在其中輸入他們的認證，通常是使用者名稱和密碼。 驗證憑證之後，使用者會被重新導向至其原先要求的頁面。 表單驗證通常會採用 Cookie 在伺服器與用戶端瀏覽器之間傳遞使用者憑證。

以下各節說明計劃將表單驗證新增到您網站時的相關須知：

  1. 表單驗證基本概念
  2. 驗證 Cookie

表單驗證基本概念

ASP.NET 表單型驗證適用於接收許多要求之公用網頁伺服器上的網站或應用程式。 這種驗證模式可讓您管理應用程式層級的用戶端登錄和驗證，而不需依賴作業系統提供的驗證機制。

重要

由於表單驗證會將使用者名稱和密碼以純文字形式傳送到網頁伺服器，因此請針對您應用程式中的登入頁面和首頁以外的所有其他頁面使用安全通訊端層 (SSL) 加密。 如需 SSL 的相關資訊，請參閱 4.5。TLS/SSL 通訊。

表單驗證可讓使用者使用 ASP.NET 成員資格資料庫中的身分識別登入。 這種驗證方法會利用重新導向到 HTML 登入頁面來確認使用者的身分識別。 您可以在站台或應用程式層級設定表單驗證。

表單驗證相當方便，原因如下：

  • 它可以允許使用自訂資料存放區 (例如 SQL Server 資料庫) 或 Active Directory 來進行驗證。
  • 它可以很容易地與 Web 使用者介面整合。
  • 用戶端可以使用任何瀏覽器。

如果您想要使用成員資格角色來進行授權，請使用表單驗證或類似的自訂驗證方法。

重要

如果您選取表單驗證，就無法同時使用任何查問式驗證方法。

表單驗證的登入 URL 預設為 Login.aspx。 您可以為造訪站台或應用程式的用戶端建立一個唯一的登入頁面。 例如，您可能想要從訪客收集特定的資訊，或提供站台或所選應用程式上所選頁面的成員資格。

表單驗證的預設逾時值是 30 分鐘。 請考慮將逾時值變更成較短的期間，以縮短工作階段存留期及減少發生 Cookie 重新執行攻擊的機會。

驗證 Cookie

驗證 Cookie 被當作權杖，用來檢查用戶端是否可存取應用程式的部份或所有頁面。 相對地，個人化 Cookie 則包含使用者特定設定，決定了使用者在特定站台或應用程式的體驗。

重要事項：由於驗證 Cookie 會與每個要求一起在用戶端和伺服器之間傳遞，因此一律使用安全通訊端層 (SSL) 保護驗證 Cookie。 如需 SSL 的相關資訊，請參閱 4.5。TLS/SSL 通訊。

與查詢字串相比，Cookie 是更有效率的站台訪客追蹤方式，因為它們不需要重新導向。 不過，它們與瀏覽器相依，而且有些瀏覽器也不支援使用它們。 此外，使用 Cookie 型驗證也不一定有效，因為有些使用者會停用其瀏覽器中的 Cookie 支援。

ASP.NET 應用程式的 Cookie 名稱預設為 .ASPXAUTH。 不過，您可以改為讓每個應用程式使用一個唯一的 Cookie 名稱和路徑。 這麼做可防止已通過一個應用程式驗證的使用者被網頁伺服器上的其他應用程式驗證。

您可以為網站或應用程式選擇下列其中一種 Cookie 模式：

[模式] 描述
使用 Cookie 不論什麼裝置，一律使用 Cookie。
不使用 Cookie 不使用 Cookie。
自動偵測 如果裝置設定檔支援 Cookie，就會使用 Cookie。 否則，不會使用任何 Cookie。 對於已知支援 Cookie 的桌面瀏覽器，ASP.NET 會檢查以判斷是否啟用 Cookie。 這項設定是預設值。
使用裝置設定檔 如果裝置設定檔支援 Cookie，就會使用 Cookie。 否則，不會使用任何 Cookie。 ASP.NET 不會檢查以判斷支援 Cookie 的裝置上是否是否啟用 Cookie。 此設定是 IIS 8 的預設值。

Cookie 保護模式定義了表單驗證 Cookie 為特定應用程式執行的功能。 下表顯示您可以定義的 Cookie 保護模式：

[模式] 描述
加密和驗證 指定應用程式同時使用資料驗證和加密來協助保護 Cookie。 這個選項會使用已設定的資料驗證演算法 (根據電腦金鑰)。 如果有三重 DES (3DES) 可用且金鑰夠長 (48 個位元組以上)，就會使用 3DES 來加密。 這個設定是預設 (且建議的) 值。
無 指定針對只將 Cookie 用於個人化且安全性需求較弱的站台同時停用加密和驗證。 我們不建議您這樣使用 Cookie；不過，這是使用 .NET Framework 來啟用個人化時最不耗費資源的方式。
加密 指定使用三重 DES 或 DES 來加密 Cookie，但不對 Cookie 執行資料驗證。 以這種方式使用 Cookie 可能會受到純文字攻擊。
驗證 指定可確認已加密之 Cookie 的內容在傳輸中未經變更的驗證配置。

重要

基於安全性考量，請考慮將「加密」和「驗證」Cookie 分開。 就安全性暴露而言，加密 Cookie 遭竊比驗證 Cookie 遭竊更嚴重。

如果應用程式包含用戶端經常要求的物件，請透過快取這些物件來改善應用程式效能。 如果使用者在驗證 Cookie 逾時之前存取快取的物件，IIS 8 會允許快取的物件保留在快取中，並重設計時器。 不過，如果使用者在該時間未存取快取的物件，IIS 8 會從快取中移除快取的物件。

在下列情況下，請考慮啟用這個設定：

  • 您可供快取使用的記憶體數量有限。
  • 您有許多要快取的物件，因為這個設定只允許將最常被要求的物件保留在快取中。

注意

您可以使用 [驗證 Cookie 逾時 (分鐘)] 來指定驗證 Cookie 逾時前的分鐘數。

ASP.NET 模擬驗證

當您想要在與 ASP.NET 應用程式預設資訊安全內容不同的資訊安全內容下執行您的 ASP.NET 應用程式時，請使用 ASP.NET 模擬。

如果您為 ASP.NET 應用程式啟用模擬，該應用程式可以在兩個不同的內容之一中執行：以 IIS 8 驗證的使用者身分或您設定的任意帳戶執行。 例如，如果您使用匿名驗證，並選擇以已驗證的使用者身分執行 ASP.NET 應用程式，該應用程式就會在為匿名使用者設定的帳戶 (通常是 IUSR) 下執行。 同樣地，如果您選擇在任意帳戶底下執行應用程式，它就會在針對該帳戶設定的任何安全性內容底下執行。

ASP.NET 模擬預設為停用。 如果您啟用模擬，ASP.NET 應用程式會在 IIS 8 所驗證使用者的安全性內容下執行。

4.4. 電腦金鑰設定

電腦金鑰可協助保護表單驗證 Cookie 資料和頁面層級檢視狀態資料。 它們也會確認跨處理序工作階段狀態識別。 ASP.NET 會使用下列類型的電腦金鑰：

  • 「驗證金鑰」會計算「訊息驗證碼」(MAC) 以確認資料的完整性。 這個金鑰會被連結至表單驗證 Cookie 或特定頁面的檢視狀態。
  • 「解密金鑰」是用來加密和解密表單驗證票證和檢視狀態。

IIS 8 可讓您設定驗證和加密設定，並產生電腦金鑰，以便與 ASP.NET 應用程式服務搭配使用，例如檢視狀態、表單驗證、成員資格、角色和匿名識別。

在您為應用程式產生電腦金鑰之前，請先做出下列設計決策：

  • 決定要使用的驗證方法：AES、MD5、SHA1 (預設) 、TripleDES、HMACSHA256、HMACSHA384 或 HMACSHA512。
  • 決定要使用的加密方法：自動 (預設) 、AES、TripleDES 或 DES。
  • 決定是否要在執行階段自動產生驗證金鑰。
  • 決定是否要為每個應用程式產生一個唯一的驗證金鑰。
  • 決定是否要在執行階段自動產生加密金鑰。
  • 決定是否要為每個應用程式產生一個唯一的加密金鑰。

4.5. TLS/SSL 通訊

傳輸層安全性 (TLS) 及其前身安全通訊端層 (SSL) 是為您的網站提供通訊安全性的通訊協定。 您可以使用 TLS/SSL 來驗證伺服器和用戶端，然後使用它將已驗證之對象間的訊息加密。

在驗證程序中，TLS/SSL 用戶端會將訊息傳送至 TLS/SSL 伺服器，然後伺服器會以驗證其本身所需的資訊來回應。 用戶端和伺服器會執行其他工作階段金鑰交換，並結束 [驗證] 對話方塊。 驗證完成時，即可使用在驗證過程中建立的對稱式加密金鑰，在伺服器與用戶端之間開始進行 SSL 安全保護通訊。

若要為您的網站設定 TSL/SSL，請執行下列各項：

  1. 從憑證授權單位 (CA) 取得伺服器憑證。 請參閱伺服器憑證。
  2. 為網站新增 SSL 繫結。 請參閱 SSL 繫結。
  3. 設定 IIS 以要求在站台使用 SSL。 請參閱您的站台需要使用 SSL。
  4. 請考慮為您的站台使用用戶端憑證。 請參閱用戶端憑證。

伺服器憑證

您可以從憑證授權單位 (CA) 取得伺服器憑證。 從憑證授權單位取得伺服器憑證是設定安全通訊端層 (SSL) 或傳輸層安全性 (TLS) 中的一個步驟。 您可以從協力廠商 CA 處取得伺服器憑證。 協力廠商 CA 可能會先要求您提供身分識別證明，然後才會簽發憑證。 您也可以藉由使用線上 CA (例如「Microsoft 憑證服務」) 來簽發您自己的伺服器憑證。

數位憑證是作用像線上密碼的電子檔案，用來確認使用者或電腦的身分識別。 它們是用來建立用於用戶端通訊的 SSL 加密通道。 憑證是由憑證授權單位 (CA) 簽發的數位聲明，用來擔保憑證持有者的身分識別，並可讓當事人藉由使用加密來以安全的方式通訊。

數位憑證可執行下列作業：

  • 他們驗證其持有者、網站，甚至是路由器等網路資源，確實是誰或他們所宣告的內容。
  • 它們會保護線上交換的資料，以避免資料遭竊或遭到竄改。

數位憑證是使用「憑證服務」由受信任的協力廠商 CA 或 Microsoft Windows 公開金鑰基礎結構 (PKI) 所簽發，或是以自我簽署的方式簽發。 每種類型的憑證都有優點和缺點。 每種類型的數位認證都可以防止篡改且無法偽造。

可以針對數種用途來簽發憑證。 這些用途包括 Web 使用者驗證、網頁伺服器驗證、安全/多用途網際網路郵件延伸 (S/MIME)、網際網路通訊協定安全性 (IPsec)、傳輸層安全性 (TLS) 以及程式碼簽署。

憑證包含公開金鑰，並且會將該公開金鑰連結至持有相對應私密金鑰的人員、電腦或服務的身分識別。 用戶端和伺服器會使用公開和私密金鑰先將資料加密，然後再傳輸資料。 就 Windows 型使用者、電腦及服務而言，當可信任的根憑證存放區中有一份根憑證，而且該憑證包含有效的憑證路徑時，就會建立 CA 信任關係。 憑證必須是尚未被撤銷且有效期間尚未過期，才會被視為有效。

SSL 繫結

當您的站台內容提供各種不同用途的服務，或是您必須讓站台使用不同的通訊協定時，您可以為站台指派多個繫結。 例如，商務網站可能會有要求使用者在登入帳戶後才能購買商品的應用程式。 公司是透過 HTTP 來主控網站，但使用者必須在 HTTPS 頁面上登入其帳戶。 在這個範例中，該站台會有兩個繫結：一個用於 HTTP 部分，另一個則用於 HTTPS 部分。

在原始設定中，您無法使用「IIS 管理員」新增 HTTP 和 HTTPS 以外之通訊協定的繫結。 如果您想要新增不同通訊協定 (例如 Windows Communication Foundation (WCF) 支援的通訊協定) 的繫結，請使用其中一項其他的系統管理工具。 不過，如果您安裝 IIS 檔案傳輸通訊協定 (FTP) 伺服器，就可以使用「IIS 管理員」來新增 FTP 繫結。 可能也有其他可擴充 UI 的模組或協力廠商功能可供下載。

您的站台需要使用 SSL

安全通訊端層 (SSL) 加密會保護在用戶端與伺服器之間傳送的機密或個人資訊。 已啟用 SSL 時，遠端用戶端會使用以 https:// 開頭的 URL 來存取您的網站。

請先設定伺服器憑證並建立 HTTPS 繫結以啟用任何 SSL 設定。 然後要求在下列一或多種情況下使用安全通訊端層 (SSL) 加密：

  1. 當您伺服器上的機密或個人內容必須受加密的通道保護時。
  2. 當您想要讓使用者能夠在他們傳輸個人資訊之前先確認您伺服器的身分識別時。
  3. 當您想要使用用戶端憑證來驗證存取您的伺服器的用戶端時。

用戶端憑證

當您希望用戶端在存取您網頁伺服器上的內容之前先驗證其身分識別時，請設定用戶端憑證。 用戶端憑證預設會被忽略。

您必須先設定伺服器憑證並建立 HTTPS 繫結以啟用任何安全通訊端層 (SSL) 設定，才能在網站上設定用戶端憑證。

如果您希望所有用戶端都確認其身分識別，請指定用戶端憑證為必要。 如果某些用戶端可以在不先確認其身分識別的情況下存取內容，請指定已接受該用戶端憑證。