在配置系統中安全地存儲數據是一個難以解決的問題。早年，當我在 ASP.NET 團隊的時候，這一特定功能（安全地存儲連接字符串）好像不會得到實現了。它被無數個問題（如密鑰存儲）團團包圍，阻礙了解決之路。幸運的是，這個問題不但最終得到了解決，而且還融入到 ASP.NET 2.0 強大的最新 API 組合中，從而使您得以通過編程方式管理 ASP.NET 配置文件。
不過，在深入探究 ASP.NET 2.0 之前，讓我們先研究一下這個問題，了解一下 ASP.NET 1.x 中的各種解決方案。只要您用過 ASP.NET，那么，您無疑會理解在 web.config 文件中存儲共享設置的好處。例如，您不必在每次創建新數據庫連接時都指定連接字符串，而是可以將該字符串存儲在 ASP.NET 配置文件的 <appSettings /> 節中。這樣就可以通過 ConfigurationSettings.AppSettings 屬性訪問連接字符串。下面是一個 <appSettings/> 節的示例：
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="ConnectionString"
value="server=.;database=demo;uid=db;pwd=*u%a" />
</appSettings>
</configuration>
這樣，每當您需要更改連接字符串時，只需打開該文件，執行更改，即告完成。
從傳統 ASP 轉向 ASP.NET 的許多開發人員都對此功能深有體會，因為大多數全局值都是以應用程序變量的形式存儲的。實際上，對于 ASP.NET 1.x，在 <appSettings/> 中存儲連接字符串是一種推薦的做法。還有一點也值得注意，就是您也可以在 <appSettings/> 中存儲其他常用數據，包括 LDAP 路徑、常用應用程序設置以及應用程序所需要的其他數據。<appSettings/> 的目標是簡化自定義配置節處理程序的編寫，這是一項與 ASP.NET 配置系統交互的更高級的技術。自定義配置節處理程序允許您在配置系統內創作和處理自己的 XML 節。
您也許已經注意到，在 <appSettings/> 中存儲的內容沒有加密，而是以純文本的形式存儲。<sessionState/> 節也是如此，該節支持在進程外存儲 Session 數據。一種備選的存儲方式是使用 SQL Server?，并在 <sessionState/> 配置位置中以純文本形式存儲憑據。
等一等，您不能這樣做
在 <appSettings/> 中存儲連接字符串的缺點是不能保證安全性，因為該文件沒有經過加密，也沒有經過編譯。并不是說編譯配置信息就會對增強安全性有所幫助；DVD 制造商使用基于密鑰的加密方法來保護知識產權，方法是簡單地讓 DVD 播放器軟件供應商將解密密鑰存儲在他們的編譯代碼中。某些黑客編寫的一小段代碼會輕而易舉地找到解密密鑰。我們常常會在個人網絡日志中看到這樣的帖子，有人想弄清某種東西在 Microsoft? .NET Framework 中的工作機理，這時就會有人建議：“試試 Reflector�！�
ASP.NET 1.1 — 更好地保守秘密
在 ASP.NET 1.0 中，如果沒有額外的自定義代碼，則無法在配置文件中安全地存儲連接字符串。ASP.NET 團隊在 ASP.NET 1.1 中解決了這個問題，方法是對幾個配置條目啟用加密。該解決方案是通過 Windows 數據保護 API (DPAPI) 完成的，從而能夠加密下列配置條目：
<identity/> 用來存儲 ASP.NET 輔助進程的 Windows? 標識以供模擬之用。
<processModel/> 用來控制在其下執行 ASP.NET 輔助進程的 Windows 帳戶。IIS 6.0 中不使用（請參閱以下注釋）。
<sessionState/> 具體包含 stateConnectionString 和 sqlConnectionString 屬性，用于控制 ASP.NET 對進程外狀態服務器的驗證方式。
需要注意的很重要的一點是，IIS 6.0（Windows Server? 2003 附帶的 Web 服務器）提供了它自己的輔助進程管理子系統，而 ASP.NET 會順從該系統。因此，ASP.NET 在由 IIS 6.0 托管時，配置系統中的有些輔助進程設置將不被使用。
隨 ASP.NET 1.1 提供了名為 aspnet_setreg.exe 的工具，用以加密配置文件中的數據并將解密密鑰存儲在 Windows 注冊表項中。得到的注冊表項具有一個訪問控制列表 (ACL)，該列表配置為限制有權訪問該密鑰的 Windows 帳戶�！爸R庫”文章 Q329290“如何使用 ASP.NET 實用工具加密憑據和會話狀態連接字符串”中詳細介紹了這項技術。
不過，這個解決方案也有一些缺點。它破壞了 ASP.NET 團隊所鐘愛的 xcopy 部署，該功能允許在無需訪問服務器的情況下部署 ASP.NET 應用程序。運用上文提到的技術，開發人員或系統管理員必須具有本地計算機的訪問權限，才能運行命令行工具，進而加密配置數據并將密鑰存儲在注冊表中。
ASP.NET 2.0 秘密s
接下來我們可以開始討論該團隊為s在 ASP.NET 2.0 中解決這一問題而做的所有工作了。這次又有一個用于管理配置數據加密的命令行工具：aspnet_regiis.exe。Aspnet_regiis.exe 存在于 ASP.NET 的早期版本中，主要用于手動向 IIS 注冊 ASP.NET。例如，使用它向 IIS 添加 aspnet_isapi.dll 以及配置 ASP.NET 應用程序使用的腳本目錄。您可在 \Windows\Microsoft.NET\Framework\版本號\ 目錄中找到此工具。
使用 aspnet_regiis.exe 加密配置節的過程同它所生成的結果一樣撲朔迷離！請看圖 1 中 aspnet_regiis.exe /help 的執行結果，您就明白我的意思了。
正如您所看到的那樣，除非您非常熟悉安全術語，否則您很快就會被大量的選項和各種設置弄的眼花繚亂。不幸的是，雖然功能強大，但各種工具十分混亂�，F在我們暫不研究 aspnet_regiis.exe 的使用方法，先來看一個 ASP.NET 示例頁面，該頁面使用新的配置 API 來實現配置節的加密。此頁面，即 ConnectionEncryption.aspx（可以從 MSDN?Magazine 網站上獲得），包含一個 GridView，用所有配置節的列表填充。如圖 2 所示。
在研究 ConnectionEncryption.aspx 內部的工作方式之前，先看看這個頁面的結果。但是先提出一個警告：使用本工具要求托管 ASP.NET 的進程對當前應用程序的 web.config 文件具有寫入權限。默認情況下，IIS 中運行的 ASP.NET 應用程序沒有必要的權限。不過，托管在 ASP.NET Development Web Server 中的應用程序使用已登錄用戶的權限集運行。您在此處看到的該工具的所有用法都是在 ASP.NET Development Web Server 中顯示的。建議您在全面了解更改 IIS 權限設置所帶來的影響的情況下再執行更改。
下面是 web.config 中用于存儲連接字符串的全新 <connectionStrings> 節的示例條目。<connectionStrings> 節與 <appSettings> 節幾乎相同，目前建議在前者中存儲連接字符串數據，因為有新的 API 可以專門處理散布在 ASP.NET 中的連接字符串：
<connectionStrings>
<add name="Northwind" providerName="System.Data.SqlClient"
connectionString="Server=localhost;Integrated
Security=True;Database=Northwind" />
</connectionStrings>
請注意，在這種情況下，仍然使用 Windows 驗證連接到數據庫。
單擊 ConnectionEncryption.aspx 中的 Encrypt（加密）鏈接，將 web.config 中連接字符串的值更改為如圖3 中所示的內容。加密后，ConnectionEncryption.aspx 頁面會將該條目的狀態報告為已加密（鏈接會更改為“Decrypt”（解密），正如您在圖 4 中所見）。
既然頁面已經生效，讓我們來看一下代碼。請看 ConnectionEncryption.aspx.cs 中的第 18 行，在 Page_Load 中，當新的 ASP.NET 2.0 WebConfigurationManager 類檢索到本地路徑的 Configuration 類的實例時，即填充 GridView：
Configuration config =
WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath);
使用從配置變量中檢索到的數據填充數組列表，然后將其綁定到 GridView。源中的大多數其他方法（請參閱下載的代碼）用于與實際數據綁定操作有關的業務邏輯規則，如確定節的范圍和狀態（加密或取消加密）。當單擊 Encrypt（加密）或 Decrypt（解密）鏈接時，GridView1_RowCommand 事件中便會發生神奇的事情。當 GridViewCommandEvent.CommandName 的值為“Encrypt”（加密）時，執行以下代碼：
section.SectionInformation.ProtectSection(
"DataProtectionConfigurationProvider");
config.Save();
當 GridViewCommandEvent.CommandName 的值為“Decrypt”（解密）時，則執行以下代碼：
section.SectionInformation.UnprotectSection();
config.Save();
這樣，就將加密和解密數據的實際工作轉交給了提供程序。一個內置提供程序是 DataProtectionConfigurationProvider。它使用內置的 DPAPI 來存儲安全數據，這與 ASP.NET 命令行工具所使用的相同。
您應該注意，加密數據時，可以指定提供程序，但解密時，卻不需要指定提供程序（如果為 ProtectSection 提供的是 null 或空字符串，則將使用在配置文件的 configProtectedData 節中指定的默認提供程序）。這是因為 API 將另一條目寫入了配置文件中，該條目用于指定所使用的加密保護提供程序：
<connectionStrings configProtectionProvider=
"DataProtectionConfigurationProvider">
<EncryptedData>...</EncryptedData>
</connectionStrings>
此配置條目不僅供 API 用以確定如何解密各個節，而且在 ASP.NET 需要將值（如連接字符串）讀入內存但必須先加以解密時，供 ASP.NET 在內部使用。
ASP.NET 2.0 的新增加密功能的一大優點是，您不但可以加密許多內置配置節，還可以編寫自定義的加密提供程序！提供程序是 ASP.NET 2.0 中一個令人驚嘆的新擴展模型，它使得開發人員能夠實現他們自己的核心功能，如成員身份、個性化等等。此外，鑒于“配置加密”的實現方式，自定義配置節也可以輕松得到加密，因而，對數據的保護不會象 ASP.NET 1.1 中那樣，僅僅局限于少數配置節。
說點更高明的秘密
關于加密機密數據的專欄如果不提出幾條警告，就不算是完整的專欄。首先，如果能避免保密，就盡量避免保密。如果您使用的是 SQL Server，而且不想在配置系統中存儲敏感的連接字符串信息，則使用 SQL Server 附帶的集成驗證。Windows 驗證用于應用服務器與數據庫之間的連接。利用此技術，與 SQL Server 之間的連接會直接通過 Windows 進行驗證和授權。使用 Windows 驗證時，SQL Server 會向驗證服務器（無論本地還是遠程的）請求令牌，該令牌包含用戶的安全標識符 (SID) 及其他信息，然后將這些信息與 SQL Server 所維護的列表進行比較，確定是準許還是拒絕訪問。配置文件中不存儲密碼或用戶名。
另外一件需要切記的事情是，僅僅安全存儲了配置文件中的數據并非意味著您可以逃開各種各樣的攻擊。任何稱職（安全雙關語）的攻擊者，只要他獲得了訪問您的服務器上的 web.config 文件的足夠權限，都可能會對您造成巨大危害。獲得系統訪問權限、能夠處理 web.config 的攻擊者可以執行其他操作來操縱數據庫，而無需知道連接字符串是什么。因此，安全存儲您的連接字符串或其他應用程序數據只是防線之一。另外一項有效防御措施是，使用存儲過程并且對那些有權訪問您的數據庫的帳戶設置更加嚴密的控制。例如，如果存在 SQL 注入漏洞，加密的連接字符串將毫無價值（有關 SQL 注入攻擊的詳細信息，請參閱 msdn.microsoft.com/msdnmag/issues/04/09/SQLInjection）。
我曾構建并運行過很多高訪問量的網站（如 http://www.asp.net/），因此我受到攻擊的機率并不比常人更低。一個常見的特征是攻擊常常與最初的漏洞毫無關系。攻擊者不會通過最初漏洞攻擊，而是會努力保護通過最初的漏洞而制造的后門。
結束語
雖然 ASP.NET 的任一版本都可以保護 ASP.NET 應用程序中的機密數據，但這在 ASP.NET 1.1 中較容易實現，而在 ASP.NET 2.0 中更是輕而易舉。使用 ASP.NET 2.0，配置加密不再是亡羊補牢，它已經內置于新的配置 API 之中。使用 ASP.NET 2.0，您不但可以使用 aspnet_regiis.exe 工具來加密配置節，還可以編寫您自己的自定義代碼（以及自定義提供程序，如果需要）來加密和解密配置數據。
文章來源于領測軟件測試網 http://www.kjueaiud.com/