保護成員資格的安全

更新:2007 年 11 月

ASP.NET 成員資格提供管理和認證使用者的功能,最常搭配表單驗證以及驗證控制項使用,如 LoginLoginViewLoginStatusLoginNamePasswordRecoveryCreateUserWizard 控制項。本主題描述如何透過設定網站以及使用成員資格類別撰寫程式碼的最佳作法,最佳化成員資格功能的安全性。

遵循這些最佳作法能夠改進應用程式的安全性,重要的是能夠讓您同時使用 Microsoft Windows 和網際網路資訊服務 (IIS) 的最新安全性修補檔案,以及任何 Microsoft SQL Server 或其他成員資格資料來源修補檔案,將應用程式伺服器維持在最新狀態。

如需撰寫安全程式碼以及設定應用程式安全性的最佳作法詳細資訊,請參閱 Michael Howard 和 David LeBlanc 所著的《撰寫安全的程式碼》,以及「Microsoft 典範與實例」提供的指南 (https://www.microsoft.com/taiwan/resources/practices/default.mspx)。

保護成員資格組態的安全

預設會啟用 ASP.NET 應用程式的成員資格功能,並且無法停用。預設組態設定會設定為最安全的值。如需成員資格組態設定和其預設值的詳細資訊,請參閱 membership 項目 (ASP.NET 設定結構描述)。您應該將 requiresQuestionAndAnswer 屬性設定為 true,特別是當 enablePasswordReset 或 enablePasswordRetrieval 同樣是 true 時。

保護組態值安全

儲存敏感應用程式資訊至組態檔案時,您應該使用「受保護的組態」將敏感資料加密。資訊 (特別是敏感的資訊) 包含了儲存在 machineKey 組態項目中的加密金鑰,以及儲存在 connectionStrings 組態項目中的資料來源連接字串。如需詳細資訊,請參閱使用受保護的組態加密組態資訊

保護加密金鑰和雜湊的安全

強烈建議您使用 passwordFormat 屬性設定為 Hashed 或 Encrypted 的方法,加密成員資格資料來源中的使用者密碼,其中 Hashed 是最安全的格式。指定加密演算法的加密金鑰值會儲存在 machineKey 組態項目中。根據所選取的加密演算法,指定隨機產生適當長度的加密金鑰值,以獲得增強的加密法。

在裝載多重應用程式的伺服器上,建議您為每個應用程式定義唯一的加密金鑰。較不安全的替代方案是定義單一加密金鑰,然後搭配金鑰指定 IsolateApps 選項。

您可以將主機伺服器上的電腦組態設定為拒絕應用程式覆寫組態設定。這包括拒絕在應用程式之 Web.config 檔中重新定義加密金鑰的能力。

保護成員資格資料來源連接的安全

連接字串

若要保護資料庫伺服器連接的安全性,您應該使用「受保護的組態」加密組態中的連接字串資訊。如需詳細資訊,請參閱使用受保護的組態加密組態資訊

使用整合式安全性連接 SQL Server

您應該使用「整合式安全性」連接執行 SQL Server 的電腦,避免連接字串被洩漏以及使用者 ID 和密碼被公開的可能性。當您指定一個使用整合式安全性的連接去連接一個執行 SQL Server 的電腦時,成員資格功能會還原成處理序的識別。您應該確認執行 ASP.NET (例如,應用程式集區) 的處理序識別,是預設處理序帳戶或限制的使用者帳戶。如需詳細資訊,請參閱 ASP.NET 模擬

SQL Server 資料庫使用權限

用於儲存成員資格之使用者資訊的 SQL Server 資料庫,其中包含的資料庫角色和檢視,能夠讓您限制使用者僅能存取必要的能力與可視性。您應該指派最少的必要權限,給連接至 SQL Server 成員資格資料庫的使用者 ID。如需詳細資訊,請參閱 SQL Server 應用程式服務資料庫中的角色和檢視

SQL Server Express 背景工作處理序識別

SQL Server Express 2005 包含新的作業模式,能夠啟動背景工作處理序,當做連接使用者的識別執行。這項功能稱為「以使用者身分執行」模式。雖然這個作業模式適合在使用 IIS 時進行桌上型環境開發,但是啟動背景工作處理序並不適合用在裝載多重未受信任客戶程式碼基底的 Web 伺服器上。包含應用程式的共用裝載伺服器,在互不信任的情況下,應該明確停用「以使用者身分執行」功能。您可以連接至 SQL Express 執行個體 (例如,osql –E –S .\sqlexpress) 然後發出下列 Transact-SQL 命令,以便關閉這項功能。

EXEC sp_configure 'show advanced option', '1'

GO

RECONFIGURE WITH OVERRIDE

GO

EXEC sp_configure 'user instances enabled', 0

GO

RECONFIGURE WITH OVERRIDE

GO

保護使用成員資格的 Web 網頁安全

使用敏感資料,例如登入頁面的應用程式頁面,應該使用標準的 Web 安全性機制進行保護。其中包含一些考量,例如使用 Secure Sockets Layer (SSL),並且要求使用者要登入才能執行像是更新使用者資訊,或刪除使用者的敏感作業。

此外,頁面上不應該以明文公開機密功能資料,例如密碼和使用者名稱 (某些情況下)。請確定顯示這類資訊的頁面使用 SSL,並且只能由已驗證的使用者使用。此外,避免將敏感的功能資料儲存在 Cookie 中,或是透過不安全的連接進行傳送。

保護不受拒絕服務攻擊

如果某些用戶端同時呼叫執行更新或大量搜尋作業的方法,可能會降低成員資格資料來源的回應程度。若要減少曝露在拒絕服務攻擊的危險性,請限制只有系統管理使用者,才能使用執行資料庫更新或搜尋的方法存取 ASP.NET 網頁;而在一般使用時只公開提供驗證和密碼管理的 ASP.NET 網頁。

錯誤訊息和事件

例外狀況

若要避免機密資訊公開給不適當的對象,請設定應用程式為不顯示詳細的錯誤訊息,或只在用戶端就是 Web 伺服器本身時才顯示詳細錯誤訊息。如需詳細資訊,請參閱 customErrors 項目 (ASP.NET 設定結構描述)

事件記錄檔

如果您的伺服器執行的是 Windows Server 2003,可以藉由設定事件記錄檔安全性以及設定與事件記錄檔的大小和保留期間等相關的參數,防止間接的拒絕服務攻擊,以改進應用程式的安全性。

健康監視

成功和失敗的登入嘗試都會使用 ASP.NET 健康監視功能記錄下來。在預設組態中,這表示失敗的登入嘗試會將使用者名稱和其他診斷資訊記錄在 [應用程式] 事件記錄檔中。請確定限制事件記錄檔的存取以維持這項資訊的私用性。

自訂成員資格提供者

當建立自訂成員資格提供者時,請確定遵循安全性最佳作法以避免在使用資料庫時遭受像是 SQL-injection 的攻擊。當使用自訂成員資格提供者時,請確定已重新審查該提供者的安全性最佳作法。

使用區分文化特性的字元

當使用 SQL Server 成員資格提供者或自訂成員資格提供者時,可能會將資料來源設為以區分文化特性的格式來儲存成員資格資料。然而,ASP.NET 會將授權組態項目中的使用者名稱和成員資格資料存放區中的使用者名稱評估為不因文化特性而異,因此,未經授權的使用者可能會獲得授權,因為使用者名稱被視為不因文化特性而異時,它就等同於授權的使用者名稱。

為了避免使用者取得未經授權的存取,請確認使用者名稱在評估為不因文化特性而異時是唯一的名稱。或者,也可以使用授權組態項目來指定授權的唯一角色名稱,然後再確認角色名稱在評估為不因文化特性而異時是唯一的名稱。一般說來,傾向於使用角色名稱來指定授權,因為建立和管理角色可能會受限於系統管理的功能。

請參閱

其他資源

使用成員資格管理使用者