使用 ASP.NET 2.0 增強網站的安全性

本文以 2004 年 3 月社區技術預覽中的 ASP.NET 2.0 內容為基礎。文中包含的所有資訊有可能變更。

本文討論：

•	ASP.NET 2.0 中的安全性增強
•	伺服器端安全性控制
•	使用者和角色資料庫
•	無 cookie 的表單身分識別驗證

本文使用下列技術：

ASP.NET、身分識別驗證

本頁內容

	推進表單身分識別驗證
	入門
	伺服器端安全控制項
	定義角色
	密碼恢複
	調整提供者
	控制項調整
	成員和角色編程
	無 cookie 的表單身分識別驗證
	一些預防措施
	小結

新的安全功能是 ASP.NET 2.0 中的一項重要改進。這些功能包括系統管理使用者帳戶資料庫的成員資格服務、雜湊密碼、系統管理使用者角色成員資格的角色管理器，以及可以更容易實現表單身分識別驗證的五個新的伺服器端控制項。ASP.NET 2.0 還提供了提供者模型，使您能夠完全地控制 Membership 和 Role 服務以及無 cookie 表單身分識別驗證的實現。您還可以非常容易的對使用者帳戶和角色進行基於 Web 的本地和遠端管理，並且可以獲得對其他非安全性相關設定的增強控制。

推進表單身分識別驗證

表單身分識別驗證是 ASP.NET 1.0 中最廣泛使用的功能之一，因為它封裝了許多特定實現所缺少的最佳實務。例如，您知道有多少表單身分識別驗證實現可以保護用來存放用戶端憑證的 cookie 的完整性？表單身分識別驗證不僅將使用者名稱寫入該 cookie 中，而且還添加了一個訊息身分識別驗證代碼（一個根據該 cookie 形成的雜湊值和只有 Web 服務器知道的秘密值）。這使得惡意的用戶端不能提高特權或通過修改其 cookie 中的名稱來查看另一個使用者的資料。如果您留意 .NET Web 開發人員推出的各種新聞群組和列表格服務器，您將瞭解到人們正一遍又一遍地實現相同的東西：使用者資料庫、cookie 中緩衝的角色、捕獲使用者名稱和密碼的控制項、系統管理使用者和角色的工具。ASP.NET 組已經提供了針對幾乎所有這些問題的內建解決方案。在研究 ASP.NET 2.0 的最初測試版構建時，讓我感到震驚的是，它徹底減少了用來構建以可管理的方式使用表單身分識別驗證的網站的代碼的數量。

返回頁首

入門

當我帶您完成一些實驗時，您將看到使用這些新功能起步是多麼容易。如果您有 ASP.NET 2.0 自我裝載版（MSDN Universal 訂戶可以下載），您就可以進行這些實驗。

首先，需要有一個指向空目錄的虛擬目錄。必須確保 ASP.NET 輔助進程具有讀取、執行和寫入這個目錄的許可權。如果正在運行 Windows 2000 或 Windows XP，就需要將這些許可權授予 ASPNET 本地帳戶，而在 Windows Server 2003 下，則需要將許可權授予 Network Service 帳戶。

我將使用表單身分識別驗證，因此我需要通過 web.config 檔案來啟用它。如果我現在向您展示如何使用 ASP.NET 1.1，我會告訴您開啟一個文字編輯器並開始手動鍵入 XML。但是在 ASP.NET 2.0 中，我最喜歡的功能之一是互動式設定檔編輯器，它直接構建於 IIS 管理主控台，您可以在虛擬目錄的屬性工作表的"ASP.NET"選項卡上找到。按下"Edit configuration"按紐，將會彈出該編輯器。

圖 1 配置編輯器

圖 1 顯示了這個新的編輯器。您會看到我選擇了表單身分識別驗證而不是預設選項：Windows 身分識別驗證。在您自己的虛擬目錄中進行同樣的操作。當使用組態工具時，將 Web 應用程式的預設語言設定為 C#，因為它將替您省去一些後面需要進行的輸入。Page Language Default 設定是 Application 選項卡上的第一個下拉選項。在應用這些更改之後，您將在目錄中找到 web.config 檔案，並帶有所有設定。

您需要向 Membership 服務註冊一些使用者以便開始，因此您寫的第一頁是允許您添加使用者的頁。在該測試版中提供有一個伺服器控制項，通過該控制項，您可以使用下面三行代碼來實現該頁：

<form runat='server'><asp:createuser runat='server'/></form>

不過，由於我使用的是最初自我裝載版，所以我必須直接使用 Membership 類來手工為這個特殊的表單編寫代碼。而現在，只需使用圖 2 中所示的 ASPX 頁就可以了，我將在本文稍後討論 Membership 類。圖 3 顯示當您將瀏覽器指向該頁時所看到的內容。繼續進行實驗，現在添加一些使用者和密碼。您的工作應該輕鬆得多，因為這做得超常的好！

圖 3 Membership 頁

在添加完使用者之後，請仔細查看虛擬目錄。您應該看到一個新的名為"DATA"的子目錄，其中有一個 Microsoft Access 資料庫。這是 Membership 和 Role 服務預設儲存其資料的地方，但是稍後我會向您展示如何覆蓋預設儲存機制以使用 SQL Server，或您自己的自訂資料儲備庫。現在是使用 ASP.NET 2.0 中提供的安全控制項的時候了。

返回頁首

伺服器端安全控制項

圖 4 列出了 ASP.NET 2.0 中提供的五個新的安全控制項。從 LoginStatus 控制項開始探索是個好主意。首先建立一個包含該控制項的新 ASPX 頁。為了簡單起見，調用新頁面 default.aspx：

<form runat='server'><asp:loginstatus runat='server'/></form>

將瀏覽器指向該頁面，您應該看到一個 Login 連結。如果您在瀏覽器中查看結果頁面的原始碼，您將看到這個超級連結指向一個名為 login.aspx 的頁面，而您還沒有編寫它。這又是一個用三行代碼實現的 Web 頁，因此我們繼續進行實驗，現在就建立它：

<form runat='server'><asp:login runat='server'/></form>

如果您曾經手工實現過表單身分識別驗證，您就會讚賞這三行代碼。過去，執行資料庫尋找的等同實現需要兩倍數量的代碼。

現在回到您的瀏覽器，並單擊 Login 連結，它會把您帶到 圖 5 中所示的登入頁面。嘗試用一個無效使用者名稱或密碼登入，可以發現，系統會彈出一條適當的預設錯誤訊息。這條訊息不會給攻擊者太多的資訊。而一個沒有經驗的開發人員也決不會無意中發送回一條訊息給該使用者，告訴他獲得了正確的使用者名稱，請嘗試猜測另一個密碼！

圖 5 登入頁面

繼續進行實驗，鍵入有效使用者名稱和密碼 - 前面您通過 adduser.aspx page 頁面輸入的使用者名稱和密碼 - 您應該重新定向回 default.aspx 頁面。由於您沒有為登入控制項提供任何自訂動作，所以預設情況下它只通過表單身分識別驗證來讓您登入，這意味著您的瀏覽器現在有了一個存放使用者名稱的加密 cookie。

既然您已經重新導向回 default.aspx 頁面，您看到什麼不同嗎？登入狀態控制項現在應該顯示 Logout 而不是 Login。因為表單身分識別驗證 cookie 是與請求一起發送的，所以 FormsAuthenticationModule 建立了一個經過身分識別驗證的使用者主體，並且將其與該請求的上下文相關聯。登入狀態控制項會注意到這種情況，並且改變成允許您登出。嘗試登出並重新登入來查看這項工作。

現在，讓我們再添加一些代碼到 default.aspx 頁面：

<h3>User Name: <%= User.Identity.Name %></h3><h3>User Type: <%= User.GetType() %></h3>

重新整理這個頁面，您應該看到您用來登入的使用者名稱。注意，表示使用者的基本對象是 GenericPrincipal 類型，這是 FormsAuthenticationModule 表示使用者的方式。一旦您啟動 Role Manager，您就會注意到這種類型變化，因為當啟用時，新的 RoleManagerModule 就取代了由 FormsAuthentication 使用它自己的類型產生的使用者。

現在，讓我們添加一個 LoginView 控制項到 default.aspx 頁面來顯示可以根據使用者的登入而改變的內容。使用這個控制項最簡單的方法是提供兩個內容塊：一個用於匿名請求（在使用者登入之前），另一個用於身分識別驗證請求（在使用者登入之後）：

<asp:loginview runat='server'><anonymoustemplate><h4>If you see this, you've not yet logged in!</h4></anonymoustemplate><loggedintemplate><h4>Welcome to my website, <asp:loginname runat='server'/>!</h4></loggedintemplate></asp:loginview>

當您登入或登出時，您應該看到 LoginView 控制項中的文本發生了改變，正如我們所預料的一樣。這是一個非常簡單的想法，但是它確實讓您的代碼變得清晰了許多。

返回頁首

定義角色

我已經製作了一個簡單的頁面，它允許您使用 Role Manager 將使用者添加到角色，但是在您能夠使用它之前，您需要為您的應用程式啟用 Role Manager。回到組態工具，並找到 Authentication 選項卡。選中標有"Role management enabled"的複選框，然後應用這個改變。

addrole.aspx 頁面的代碼顯示在圖 6 中，而圖 7 顯示了表單的外觀。將這個頁面放在您的虛擬目錄中，並且將您的瀏覽器指向它，這樣您就可以添加一些角色了。指定一個使用者名稱（您前面通過 adduser.aspx 表單添加的使用者名稱）及一個角色名稱，然後按一下按紐將使用者添加到角色中。代碼首先添加角色（如果它不存在的話），然後將使用者添加到角色。在幕後，Role Manager 會在 Membership 服務使用的同一 Microsoft Access 資料庫中跟蹤這些角色映射，但是這實際上只是巧合。Role Manager 可以將其資料存放區在 SQL Server 或任何其他的儲存中，並且不必使用與 Membership 服務相同的機制。為了支援這一點，Membership 和 Role Manager 的提供者模型完全不同。

圖 7 添加角色

如果您曾經在 ASP.NET 中實現過自訂角色，您就會讚賞內建的 Role Manager，因為您不必再為了實現角色型安全性而成為 ASP.NET HTTP 管道的主人。一旦您添加了一些角色，您就可以回到 default.aspx，並且可以使用 LoginView 控制項來做一些有趣的事情。在 元素之後添加另一個部分：

<rolegroups><asp:rolegroup roles='ForumModerators'><contenttemplate><h4>Controls for forum moderatorsgo here.</h4></contenttemplate></asp:rolegroup><asp:rolegroup roles='Friends'><contenttemplate><h4>Welcome, friend!</h4></contenttemplate></asp:rolegroup></rolegroups>

您可能沒有選擇與我相同的角色，因此您將需要用您自己的角色名稱來代替我的角色名稱，並且調整內容使之適合角色。一旦您完成了，就可以通過使用不同角色中的不同使用者帳戶登入來檢驗您的新頁面，並且觀察當角色改變時頁面的內容如何改變。注意，如果兩個角色群組都與使用者的角色相匹配，則總是顯示第一個匹配的角色群組（從上到下）。

雖然這並不新鮮，但是請您記住，您總可以通過 User.IsInRole 以編程方式測試角色。還需要謹記的是，您可以使用 web.config 中的 部分來准許或拒絕訪問各個頁面，如下所示：

<authorization><deny users='?'/><allow roles='ForumModerators'/><deny users='*'/></authorization>

第一項告訴 ASP.NET 禁止傳入任何未經身分識別驗證的請求（強制執行身分識別驗證）。第二項和第三項確保只有 ForumModerators 可以訪問 web.config 檔案所駐留的分類樹中的內容。記住，授權部分可用於子目錄中的 web.config 檔案，也可以用於<location/> 元素，以控制對單獨檔案的訪問。

返回頁首

密碼恢複

在這個介紹示範中，我還沒有向您展示密碼恢複控制項，因為對它的使用需要進行仔細的考慮。您可能知道這個控制項的作用：它讓使用者請求通過電子郵件將他的密碼發送給他。在決定將純文字密碼通過電子郵件發送給使用者之前，您需要做一些風險評估。

事實上，如果您把這個控制項放在您現有網站的一個頁面上，它將不會起作用，因為在預設情況下，Membership 服務會拒絕公開純文字密碼。即使它想這樣也是不可能的，因為在預設情況下它只儲存密碼的單向雜湊值而不儲存密碼本身。當要求驗證密碼時，Membership 服務會雜湊所提交的密碼，並將該雜湊值與其副本相比較。如果您想要恢複純文字密碼，您可以將 Membership 提供者重新設定為以加密的形式儲存密碼，在這種情況下，Membership 提供者將使用<machineKey/> 來加密密碼。這樣就可以對密碼進行解密並通過電子郵件發送給使用者。

如果您儲存雜湊密碼（這真是一個好主意），您就需要準備一種替換的方法來對使用者進行身分識別驗證。您不能通過電子郵件將密碼發送給使用者，但是如果您提前問了幾個問題，比如"您最喜歡的寵物叫什麼名字？"，您就可以使用這些答案來對使用者進行身分識別驗證，並允許他向您發送一個新的密碼。然而，Membership 服務並不支援為每個使用者保留問題和答案，使用它僅僅是為了決定是否可以通過電子郵件發送密碼，因此它不能與雜湊密碼一起使用。據我看來，這方面將耗費一些工作。

在 Building Secure Software (Addison-Wesley, 2002) 的 95 頁上，Viega 和 McGraw 提出了一種通過問答來重新設定密碼的好模型。這種模型需要使用數百個問題的集合，當使用者首次設定她的帳戶時，它會隨機挑出一組問題來問使用者。如果使用者請求重新設定密碼，您就可以問她這些問題中的一部分。這需要她正確的回答許多質詢問題以便繼續進行操作。如果使用者成功地回答了所有的問題，您還可以選擇一組新的隨機問題代替前面使用的問題來進行提問。

返回頁首

調整提供者

到目前為止，我特意使用預設設定來保持它的簡單，但是您需要調整這些設定以適合您自己的環境。例如，如果您想讓 Membership 服務將其資料存放區在 SQL Server 中，您就應該選擇 AspNetSqlProvider 而不是預設的 AspNetAccessProvider。這個設定在組態工具的 Authentication 頁面。

但是如果您已經有了一個需要整合的現有使用者資料庫，該怎麼辦？它肯定不會有 AspNetSqlProvider 需要的表和列。另外，如果它在 AS/400 伺服器或 Oracle 安裝上又該怎麼辦？幸運的是，Membership 和 Role Manager 系統都構建在分層模型上，我已經在圖 8 中顯示了這個模型。您可以通過擴充定義在 System.Web.Security 命名空間中的抽象 MembershipProvider 類來完全代替 Membership 資料存放區。類似地，您可以通過擴充 RoleProvider 來代替 Role Manager 資料存放區。Rob Howard 在他的"'Nothin' But ASP.NET"專欄中更詳細地討論了提供者模型。

圖 8 提供者模型

的確，使用現有的提供者是最容易的。在最初測試版中，有兩個模型。一個與 Access 資料庫協同工作，正如您所看到的，它運行得超常的好。另一個是我先前提到的 SQL Server 提供者。到測試版時，應該還有針對 Active Directory 來驗證使用者的 Membership 提供者，以及從 Authorization Manager 中尋找角色的 Role 提供者。

即使您選擇了一個內建提供者，您還可以在 web.config 中調整它的行為。圖 9 顯示了 SQL Server Membership 提供者的提供者設定。注意 passwordFormat 設定，其中，您可以在三個選項之間進行選擇：Hashed（預設）、Encrypted 和 Clear。然後，您可以通過 enablePasswordRetrieval 和 requiresQuestionAndAnswer 屬性來選擇密碼恢複策略。當然，假如您選擇使用雜湊密碼，您就必須將 enablePasswordRetrieval 設定為 false。否則，您也可以要求使用者在系統通過電子郵件發送他的密碼之前回答一個質詢問題。

圖 9 提供者設定

資料庫的連接字串並沒有儲存在您的 web.config 檔案中，而是直接引用的。注意，此屬性稱為 connectionStringName，並且指向專門設計用來存放連接字串的 machine.config 部分。將連接字串儲存在 web.config 檔案之外是一個好主意，在您不能使用整合的身分識別驗證而不得不使用密碼時尤其如此。ASP.NET 2.0 預定支援對設定檔的敏感部分進行 XML 加密，對於 machine.config 中的連接字串部分來說，這實在是一個方便的功能。

Role Manager 可以配置為使用 cookies 或 URL munging，並且可以將角色緩衝在 cookie 中，從而減少往返角色資料庫的次數。該緩衝是智能的：如果緩衝角色的數目開始變得很大，Role Manager 將在 cookie 中緩衝最近使用的角色，而動態地尋找使用最少的角色。這種功能可能是由於需要用有限的儲存空間來支援行動裝置而激發的。

還可以調整許多其他的設定，但是我準備把它們留給您自己去研究。同時，讓我們看一看可用來調整前面使用的伺服器端安全控制項的方法。

返回頁首

控制項調整

用三行代碼就能夠建立一個登入頁面是十分簡潔的，但是一般來說，您需要對登入控制項進行一些自訂以適合您的應用程式。圖 10 顯示了一些代碼，您可以用這些代碼來代替前面建立的簡單登入頁面。另外，您還可以用您期望 Web 控制項具有的屬性來修改這些控制項的外觀。而通過 ASP.NET 2.0 中的主題支援，您不必更改代碼就可以在整個網站中維持一致的外觀。

登入控制項的一個有趣的功能是，它不必像我在這個例子中所做的一樣固定在自己的頁面。相反，您可以將其作為首頁面的一部分，這樣它就會始終出現在頁邊空白處。一旦使用者登入，實際上您就不想再看到它，因此在預設情況下，當它檢測到經過身分識別驗證的使用者已經存在時，它就會消失。您可以通過 VisibleWhenLoggedIn 屬性來調整這種行為。這是開發人員使用 ASP.NET 1.1 手動實現該功能的一個例子，現在它內建在 ASP.NET 2.0 中。

其他的控制項有類似的選項。例如，如果您希望為使用者登入或登出顯示一個漂亮的按鈕，則可以在登入狀態控制項上設定 Login(Out)ImageUrl 屬性。

為了感受一下它的工作方式，可以使用 Visual Studio 2005 項目嚮導來建立一個 Internet 網站。對於本文，只有在您將"Web.vssettings"IDE 設定檔案匯入 Visual Studio 的情況下才會顯示這個嚮導。您可以通過 Tools-Import/Export Settings 對話方塊來做到這一點。該嚮導包括到此為止所談到的全部功能，並且提供了豐富的 UI 自訂，以獲得您渴望新的網站具有的外觀和功能。

返回頁首

成員和角色編程

當您希望遠離伺服器端安全控制項時，最好知道您也可以直接使用實現這個進階功能的類。為了學習這些服務的編程模型，您需要分析兩個主類：Membership 和 Roles。由於文章的篇幅所限，我無法在這裡詳盡地介紹它們，而在產品向最終版本發展的過程中，其中的一些細節肯定會改變，不過，讓我首先帶您體驗一下。

從 Membership 類中，您可以建立和系統管理使用者，其中每一個使用者都是由 MembershipUser 類的一個執行個體表示的。這個類表示使用者設定檔，包括諸如 Email、CreationDate、PasswordQuestion 等屬性。當您建立和更新這些使用者設定檔時，您可以通過 Membership 類來這樣做，因為它是分層模型，隱藏了儲存設定檔的位置和方式的細節（請參見圖 8）。此類提供了更改使用者密碼和將密碼重新設定為一個電腦產生的隨機密碼的方法，這是一個時間戳記，它跟蹤使用者的活動，從而維護目前使用者的數量（您可以通過調用 Membership 類中的 GetNumberOfUsersOnline 方法來擷取這個數目）。

要驗證一個使用者密碼，只需調用 Membership 類中的 ValidateUser 方法並傳入使用者名稱和密碼就可以了。基本提供者將負責所有必要的密碼雜湊和解密。如果使用者忘記它的使用者名稱，可以通過要求他提供一個電子郵件地址並且將其傳送給 GetUserNameByEmail 方法來提醒他，但這不是一個安全的選擇。

返回頁首

無 cookie 的表單身分識別驗證

當我教授 ASP.NET 表單身分識別驗證時遇到最多的抱怨之一就是它需要 cookie。幸運的是，在 ASP.NET 2.0 中沒有這種限制。web.config 中的 元素上有一個新的"cookieless"屬性。您可以將此屬性設定為以下四個值之一：UseCookies、UseUri、UseDeviceProfile 或 AutoDetect。

UseCookies 和 UseUri 分彆強制要求 FormsAuthenticationModule 對所有的請求使用 cookies 或者 URL munging。UseDeviceProfile 用於查看瀏覽器功能以確定使用哪種模式。最後，AutoDetect 將嘗試設定 cookie，而如果失敗，就將改為使用 URL munging。典型的 URL 在保護之後如下所示（省略符號是我添加的，因為這些 URL 可能很長）：http://www.acme.com/foo/(F(Cvc...A1))/default.aspx。

URL 中括弧內的部分包含 cookie 通常包含的資料，並且將被 HTTP 管道中的模組取消，因此如果您從 ASPX 頁面讀取 Request.Path 屬性，您將不會在 URL 中看到任何多餘的內容。如果您重新導向請求，URL 會自動被保護。換句話說，這段代碼將（正確地）帶您回到您當前正在查看的頁面（在 URL 被正確保護的情況下）：

Response.Redirect(Request.Path)

這種功能應該使表單身分識別驗證在很大程度上得以更廣泛地實現。然而，隨著使用 ASP.NET 表單身分識別驗證的網站不斷增多，越來越多的攻擊者會試圖發現弱點，因此遵守一些基本規則是一個好注意。

返回頁首

一些預防措施

如果不通過安全通訊端層 (SSL) 進行保護，表單身分識別驗證並不非常強大。至少應該通過安全連線將您的登入頁面發送給使用者並傳送回 Web 服務器，以防止竊聽者竊取使用者的純文字密碼。但通常這樣做並不夠。由於 cookies 工作方式的緣故，竊取表單身分識別驗證 cookie 的竊賊已經竊取了登入資訊，因而無法實現重播檢測。記住，cookie 通常與每個請求一起發送，甚至對於像請求頁面上按鈕的 GIF 檔案這樣簡單的事情也是如此。一旦被盜，攻擊者就可以使用該 cookie 來模仿使用者。為了減少這種風險，您需要大大縮短 cookie 逾時，或者通過 SSL 運行網站的整個部分（或者還更好一些，整個網路）。

對於需要高安全性的網站，我更願意選擇後者，當人們抱怨 SSL 運行緩慢時，我問他們為什麼不去購買硬體來加速它。然而，一些公司僅僅在部分網站中堅持使用 SSL。如果您是這種情況，您可以通過啟用 元素中的 requireSSL 屬性來減少這些 cookie 重播攻擊。這會將"Secure"屬性添加到表單身分識別驗證 cookie，它指示瀏覽器應該僅通過安全通道將 cookie 發送回伺服器。換句話說，它不會與不通過 SSL 啟動並執行請求一起發送。這種功能是在 .NET 架構 的 1.1 版中增加的，因而不是 ASP.NET 2.0 所專屬的。ASP.NET 2.0 中新增的特性是，這種對策還可以應用於會話 cookie：

<httpCookies requireSSL='true' httpOnlyCookies='true'/>

由於安全的 cookie 不會與不通過 SSL 啟動並執行請求一起發送，所以對於可以通過原始 HTTP 進行訪問的頁面，您可以肯定 User.Identity.IsAuthenticated 每次都會返回 false。換句話說，您將不知道那些在任意頁面上不通過 SSL 啟動並執行使用者是誰。注意，即使您決定通過 SSL 來運行整個網站，在您偶然允許通過原始 HTTP 訪問一兩個檔案的情況下，啟用 requireSSL 屬性確實是一個好主意。

作為防止跨網站指令碼攻擊的措施，httpOnlyCookies 屬性是非常有用的；它指示瀏覽器不應該從指令碼訪問 cookie。它使用一個名為 HttpOnly 的 cookie 屬性，目前只有新版的 Internet Explorer 才能識別它，但這是個很好的主意，我希望其他的瀏覽器廠商採用它。要學習更多的知識，請參閱 Some Bad News and Some Good News。

返回頁首