本頁內容
本模塊內容
安全的 ASP.NET Web 應用程序依賴於完全安全的網絡、主機和平臺基礎結構。當上述條件滿足後，攻擊者將嘗試利用 Web 應用程序和 Web Services（通常在端口 80 上偵聽）中的漏洞。如果未有效配置 Web 應用程序，攻擊者可能會獲得系統的訪問權限並利用系統。
作爲管理員，您必須檢查默認的計算機級配置和各個應用程序配置，以處理和刪除所有漏洞或不安全設置。
本模塊從系統管理員的角度描述了 ASP.NET 中的新增內容，並描述瞭如何配置計算機範圍和應用程序特定的安全設置。此外，本模塊還提供了確保 ASP.NET Web 應用程序和 Web Services 安全的方法，這種方法是爲確保網絡、應用程序服務器、數據庫服務器和 Web 服務器安全而推薦的方法的補充。
目標
使用本模塊可以實現：
| • |
使用 Aspnet_setreg.exe 實用程序在註冊表中存儲憑據和連接字符串。 |
| • |
使用配置文件 (*.config) 管理 Web 應用程序環境。 |
| • |
瞭解如何分層實施和處理 Machine.config 和 Web.config。 |
| • |
鎖定配置設置。 |
| • |
強制實施計算機範圍和 Web 應用程序安全策略。 |
| • |
使用 <location> 元素自定義文件和目錄安全設置。 |
| • |
確保 ASP.NET 進程標識的安全，並在 ASP.NET 應用程序中使用自定義模擬。 |
| • |
瞭解 ASP.NET 進程帳戶所需的 NTFS 權限。 |
| • |
使用表單身份驗證和 URL 授權來保護資源。 |
| • |
確保 ASP.NET 會話狀態的安全。 |
| • |
確保 Web 場的安全並保護 bin 目錄。 |
適用範圍
本模塊適用於下列產品和技術：
| • |
Microsoft Windows Server 2000 |
| • |
Microsoft .NET Framework 1.1 和 ASP.NET 1.1 |
| • |
Microsoft SQL Server 2000 |
如何使用本模塊
本模塊着重描述了 ASP.NET 應用程序的主要安全注意事項。爲了充分理解本模塊內容，請：
| • |
閱讀模塊 16 保護 Web 服務器。本模塊描述瞭如何確保 Windows 2000 操作系統和 Microsoft .NET Framework 的安全。安全的基礎平臺是確保 ASP.NET Web 應用程序或 Web Services 安全的前提。 |
| • |
使用快照。表 19.4（在本模塊結尾部分）中顯示了安全 ASP.NET 應用程序的快照，該應用程序在 Machine.config 和 Web.config 中具有安全的配置設置。可在配置服務器和應用程序設置時使用此表。 |
| • |
使用檢查表。本指南“檢查表”部分的檢查表：保護 ASP.NET 的安全提供了可打印的作業指導，以供快速參考。使用基於任務的檢查表可以快速評估需要哪些步驟，並幫助您逐步完成各個步驟。 |
要獲取相關指南，請閱讀模塊 20 駐留多個 ASP.NET 應用程序，本模塊描述瞭如何將同一服務器上運行的多個 Web 應用程序與重要的系統資源隔離，以及如何將各個 Web 應用程序彼此隔離。有關配置部分信任 Web 應用程序和 Web Services 的代碼訪問安全性 (CAS) 策略的詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。
方法
要確保 ASP.NET 應用程序的安全，應先強化操作系統和 .NET Framework 安裝基準，然後應用安全的應用程序配置設置，以減小應用程序的受攻擊面。
這些措施包括：
| • |
服務。.NET Framework 安裝了 ASP.NET 狀態服務，以管理進程外的 ASP.NET 會話狀態。請確保 ASP.NET 狀態服務的安全（如果已安裝該服務）。如果不需要，請禁用 ASP.NET 狀態服務。 |
| • |
協議。限制 Web Services 協議以減小攻擊面。 |
| • |
帳戶。創建默認的 ASPNET 帳戶，用來運行 Web 應用程序、Web Services 和 ASP.NET 狀態服務。如果創建自定義帳戶以運行進程或服務，必須將其配置爲最小特權用戶，使其具有必需的 NTFS 權限和 Windows 特權的最小集合。 |
| • |
文件和目錄。應確保用來保存私有程序集的應用程序 bin 目錄的安全，以降低攻擊者下載業務邏輯的風險。 |
| • |
配置存儲。許多控制功能區域（如驗證、授權、會話狀態等）的安全相關設置在 Machine.config 和 Web.config XML 配置文件中進行維護。要確保 ASP.NET 應用程序的安全，必須使用安全的配置設置。 |
必備知識
在採取措施確保 Web 應用程序和 Web Services 的安全之前，應該瞭解一些基本注意事項和詳細信息。
ASP.NET 處理模塊
在 Microsoft Windows 2000 中，Internet 信息服務 (IIS) 5.0 在 ASP.NET 工作進程 (Aspnet_wp.exe) 中運行所有的 Web 應用程序和 Web Services。隔離單元是應用程序域，每個虛擬目錄都有自己的應用程序域。進程級的配置設置由 Machine.config 中的 <processModel> 元素維護。
在 Microsoft Windows Server 2003 中，IIS 6.0 應用程序池允許使用單獨的進程隔離應用程序。有關詳細信息，請參閱模塊 20 駐留多個 ASP.NET 應用程序。
ASP.NET 帳戶
ASPNET 帳戶是安裝 .NET Framework 時創建的最小特權本地帳戶。默認情況下，它將運行 ASP.NET 工作進程和 ASP.NET 狀態服務。
如果您決定使用自定義帳戶運行 Web 應用程序，請確保使用最小特權配置該帳戶。這將降低攻擊者企圖使用應用程序的安全上下文執行代碼的風險。此外，還必須在 <processModel> 元素上指定帳戶憑據。請確保沒有以純文本形式存儲憑據。應使用 Aspnet_setreg.exe 工具在註冊表中存儲加密憑據。自定義帳戶也必須授予適當的 NTFS 權限。
Aspnet_setreg.exe 與進程、會話和標識
Aspnet_setreg.exe 允許在註冊表中以加密格式存儲憑據和連接字符串。此工具允許加密下列屬性：
| • |
<processModel userName = password= /> |
| • |
<identity username = password= /> |
| • |
<sessionState sqlConnectionString = stateConnectionString= /> |
以下示例顯示了運行 Aspnet_setreg.exe（以確保憑據安全）前後自定義帳戶的 <processModel> 元素：
<!--運行前--> <processModel userName="CustomAccount" password="Str0ngPassword" /> <!--運行後--> <processModel userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,password"/>
可以選擇存儲加密數據的註冊表位置，但必須在 HKEY_LOCAL_MACHINE 下。除了使用數據保護 API (DPAPI) 加密數據並將其存儲在註冊表中之外，此工具還應用安全的 ACL 來限制對註冊表項的訪問。註冊表項上的 ACL 爲系統、管理員和創建者所有者授予完全控制權限。如果使用工具加密 <identity> 元素的憑據或 <sessionState> 元素的連接字符串，還必須爲 ASP.NET 進程帳戶授予讀取權限。
要獲得 Aspnet_setreg.exe 工具以及詳細信息，請參閱 Microsoft 知識庫文章 329290 How To:Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings（英文）。
模擬不是默認設置
默認情況下，ASP.NET 應用程序不使用模擬。因此，將使用 ASP.NET 工作進程標識來執行資源訪問。必須通過創建適當配置的 ACL，爲應用程序需要訪問的 Windows 資源授予進程標識讀取權限（至少）。
如果啓用模擬，也可以模擬原呼叫方（即 IIS 驗證過的標識），也可以模擬在 <identity> 元素上指定的固定標識。有關詳細信息，請參閱本模塊後面的模擬。
通常，ASP.NET 應用程序不使用模擬，因爲它會給設計、實現和可伸縮性帶來負面影響。例如，使用模擬會阻礙有效的中間層連接池，這將限制應用程序的可伸縮性。模擬對於特定方案非常有用，例如，當應用程序使用匿名用戶帳戶的安全上下文訪問資源時。在同一服務器上駐留多個應用程序時，這是一項常用技術。有關詳細信息，請參閱模塊 20 駐留多個 Web 應用程序。
HttpForbiddenHandler、Urlscan 和 404.dll
可以使用很多技術來阻止對受限制資源的訪問。ASP.NET 提供了 HttpForbiddenHandler，可以將不應通過 HTTP 下載的 ASP.NET 文件類型映射到 HttpForbiddenHandler。可以使用 <httpHandlers> 元素應用映射。
IISLockdown.exe 提供了 404.dll。使用它可以將 IIS 配置成將不需要的文件擴展映射到 404.dll，這樣，當請求這些文件類型時，會出現“HTTP 404 - File not found”消息。
最後，可以使用 URLScan ISAPI 篩選器阻止對受限制文件類型和可執行程序的請求。URLScan 隨 IISLockdown 工具提供，也可以單獨獲取。有關詳細信息，請參閱 Microsoft 知識庫文章 307608 INFO:Using URLScan on IIS（英文），以及本指南“如何”部分中的 如何：使用 URLScan。
有關 IISLockdown 和 URLScan 的詳細信息，請參閱模塊 16 保護 Web 服務器。
AppSettings
Web.config 中的 <appSettings> 元素允許應用程序存儲配置數據，如數據庫連接字符串或服務帳戶憑據。此元素的優點是允許開發人員對配置數據的存儲和檢索進行集中化和標準化。在 Web.config 中使用單個位置也簡化了管理和部署。
敏感數據（如連接字符串和憑據）不應以純文本格式存儲在配置文件中。開發人員應該在存儲機密前使用 DPAPI 對其進行加密。
有關 AppSettings 的詳細信息，請參閱 MSDN® TV 上顯示的 AppSettings in ASP.NET，其網址爲：http://msdn.microsoft.com/msdntv（英文）。
描述 Machine.Config 和 Web.Config
.NET Framework 提供的配置管理包括範圍廣泛的設置，允許管理員管理 Web 應用程序及其環境。這些設置存儲在 XML 配置文件中，其中一些控制計算機範圍的設置，另一些控制應用程序特定的配置。
可以使用任何文本編輯器編輯 XML 配置文件，如記事本或 XML 編輯器。XML 標記區分大小寫，請確保使用正確的大小寫形式。
圖 19.1 顯示了管理員可以使用的用於配置 ASP.NET Web 應用程序的配置文件。
圖 19.1
ASP.NET 配置文件
Machine.config 和 Web.config 文件共享許多相同的配置部分和 XML 元素。Machine.config 用於將計算機範圍的策略應用到本地計算機上運行的所有 .NET Framework 應用程序。開發人員還可以使用應用程序特定的 Web.config 文件自定義單個應用程序的設置。
注意 Windows 可執行文件（如 WinForm 應用程序）是使用配置文件進行配置的。這些文件的名稱源自應用程序可執行文件的名稱，例如，App.exe.config，其中“app”是應用程序名。
對配置文件所作的更改將被動態應用，通常無需重啓服務器或任何服務，除非更改了 Machine.config 中的 <processModel> 元素，本模塊稍後將討論此元素。
表 19.1 顯示了配置文件的位置。
表 19.1：配置文件的位置
| 配置文件 | 位置 |
|
Machine.config |
%windir%\Microsoft.NET\Framework\{version}\CONFIG |
|
Web.config |
\inetpub\wwwroot\web.config |
|
Enterprisesec.config |
%windir%\Microsoft.NET\Framework\{version}\CONFIG |
|
Security.config |
%windir%\Microsoft.NET\Framework\{version}\CONFIG |
|
Security.config |
\Documents and Settings\{user}\Application |
|
Web_hightrust.config |
%windir%\Microsoft.NET\Framework\{version}\CONFIG |
有關 ASP.NET Web 應用程序 CAS 配置文件的詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。
分層策略評估
對於集中式管理，可以在 Machine.config 中應用設置。Machine.config 中的設置可以定義計算機範圍的策略，也可用來通過 <location> 元素應用應用程序特定的配置。開發人員可以提供應用程序配置文件，來覆蓋計算機策略的某些方面。對於 ASP.NET Web 應用程序，Web.config 文件位於應用程序的虛擬根目錄中，也可以位於虛擬根目錄下的子目錄中（可選）。請考慮圖 19.2 中顯示的安排。
圖 19.2
分層配置
在圖 19.2 中，AppRoot Web 應用程序在虛擬根目錄下有一個 Web.config 文件。SubDir1（非虛擬目錄）也包含其自身的 Web.config 文件，當 HTTP 請求定向到 http://AppRoot/SubDir1 時，將使用該文件。如果某個請求通過 AppRoot 定向到 SubDir2（虛擬目錄），例如，http://Server/AppRoot/SubDir2，將應用來自 AppRoot 目錄下的 Machine.config 和 Web.config 中的設置。但是，如果請求繞過 AppRoot 定向到 SubDir2，例如，http://Server/SubDir2，則只應用來自 Machine.config 的設置。
在任何情況下，基準設置都是從 Machine.config 中獲取的。接着，將從任何相關的 Web.config 文件中獲取覆蓋設置和其他設置。
如果在 Machine.config 和一個或多個 Web.config 文件中使用相同的配置元素，則來自層次結構最底層文件的設置會覆蓋較高層的設置。未在計算機級應用的新配置設置也可應用到 Web.config 文件，並且某些元素可以使用 <clear> 元素清除父級設置。
下表顯示了對於圖 19.2 中應用的 Web 請求組合，組合配置設置是從何處獲取的。
表 19.2：應用配置設置
| HTTP 請求 | 組合設置來自 |
|
http://Server/AppRoot |
Machine.config |
|
http://Server/AppRoot/SubDir1 |
Machine.config |
|
http://Server/AppRoot/SubDir2 |
Machine.config |
|
http://Server/Subdir2 |
Machine.config |
<location>
<location> 元素主要用於三個目的：
| • |
將配置設置應用於特定的應用程序文件。 |
| • |
通過在 Machine.config 中應用應用程序特定的設置進行集中管理。 |
| • |
鎖定配置設置以阻止應用程序級覆蓋。 |
可以在 Machine.config 或 Web.config 中使用 <location> 標記。對於 Machine.config，如果指定路徑，必須完全限定該路徑，使其包括網站名和虛擬目錄名，還可以包括子目錄和文件名（可選）。例如：
<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" > <system.web> . . . </system.web> </location>
注意 使用 Machine.config 的位置標記時，必須包括網站名。
對於 Web.config，路徑相對於應用程序的虛擬目錄。例如：
<location path="SubDirName/PageName.aspx" > <system.web> . . . </system.web> </location>
將配置設置應用於特定文件
使用“path”屬性對特定文件應用配置設置。例如，要將授權規則應用於 Web.config 中的文件 Pagename.aspx，請使用下面的 <location> 元素：
<location path="SubDirName/PageName.aspx" > <system.web> <authorization> <deny roles="hackers" /> </authorization> </system.web> </location>
在 Machine.config 中應用應用程序配置設置
還可以使用指定應用程序目錄路徑的 <location> 語句，在 Machine.config 中應用應用程序特定的設置。這樣有利於集中管理。例如，下面的代碼片段顯示瞭如何強制使用 Windows 身份驗證，以及如何阻止在特殊應用程序中使用模擬。
<location path="Default Web Site/YourApp"> <system.web> <authentication mode="Windows"/> <identity impersonate="false"/> </system.web> </location>
鎖定配置設置
要阻止單個應用程序覆蓋計算機級的策略配置，可將設置放入 Machine.config 的 <location> 元素中，並設置 allowOverride="false" 屬性。
例如，要應用不能在應用程序級覆蓋的計算機範圍的策略，請使用下面的 <location> 元素：
<location path="" allowOverride="false"> <system.web> ... 計算機範圍的默認值 </system.web> </location>
將 path 屬性留空表明該設置將應用於計算機，而 allowOverride="false" 可以確保 Web.config 設置不會覆蓋指定值。任何嘗試在 Web.config 中添加元素的行爲都會產生異常，即使 Machine.config 中的元素與 Web.config 中的這些元素相匹配。
Machine.Config 和 Web.Config 指南
Machine.config 中的設置爲服務器應用計算機級的默認值。如果要爲服務器上所有應用程序強制使用特定的配置，可在 <location> 元素上使用 allowOverride="false"，如上所述。這對駐留方案尤其適用，在駐留方案中，需要爲服務器上的所有應用程序強制實施安全策略的各個方面。
對於可以基於單個應用程序配置的那些設置，通常應用程序會提供 Web.config 文件。儘管可以使用多個 <location> 元素從 Machine.config 配置單個應用程序，但單獨的 Web.config 文件可以提供部署優勢，並能使 Machine.config 文件變得更小。
需要考慮的主要問題是計算機策略應該強制使用哪些設置。這取決於特定的方案。一些通用方案如下所示：
| • |
Windows 身份驗證考慮一個企業的 Intranet 門戶方案，在這個方案中，您希望將驗證與應用程序分離，並由組織通過 Active Directory 控制驗證。在此方案中，可以強制使用 Windows 身份驗證，但允許單個應用程序模擬以下配置： <location path="" allowOverride="false">
<system.web>
<authentication mode="Windows"/>
</system.web>
</location>
|
| • |
駐留方案提供駐留服務的公司需要限制應用程序，以使它們不能訪問彼此的資源，從而限制對重要系統資源的訪問。要實現此目標，可以配置所有應用程序以部分信任級別運行。例如，中級信任級別限制應用程序只能訪問自身虛擬目錄分級結構內的文件，而限制對其他類型資源的訪問。有關詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。要對服務器上的所有應用程序應用中級信任策略，請使用以下配置： <location path="" allowOverride="false>
<system.web>
<trust level="Medium" />
</system.web>
</location>
|
ACL 和權限
配置文件包含敏感數據，因此需要使用適當配置的 ACL 來限制訪問。
Machine.config
默認情況下，使用以下 ACL 配置 Machine.config：
Administrators：完全控制 System：完全控制 Power Users：修改 Users：讀取和執行 LocalMachine\ASPNET（進程標識）:讀取和執行
注意 在 Windows Server 2003 上，本地服務和網絡服務帳戶也被授予讀取權限。
Users 組的成員默認情況下被授予讀取權限，因爲計算機上運行的所有託管代碼都必須能夠讀取 Machine.config。
Machine.config 上的默認 ACL 是安全的默認值。但是，如果只有單個 Web 應用程序運行在服務器上，或所有 Web 應用程序使用相同的進程標識，則可以通過刪除用戶的訪問控制項 (ACE) 來進一步限制 ACL。如果確實從 DACL 中刪除了“users”，需要明確添加 Web 進程標識。
Web.config
.NET Framework 不安裝任何 Web.config 文件。如果安裝提供自身 Web.config 的應用程序，通常它會從 inetpub 目錄繼承 ACL，默認情況下，該 ACL 將爲 Everyone 組的成員授予讀取權限。要鎖定應用程序特定的 Web.config，請使用以下 ACL 之一。
對於 .NET Framework 1.0：
Administrators：完全控制 System：完全控制 ASP.NET 進程標識：讀取 UNC 標識：讀取 模擬標識（固定標識）：讀取 模擬標識（原呼叫方）：讀取
對於 .NET Framework 1.1：
Administrators：完全控制 System：完全控制 ASP.NET 進程標識：讀取 UNC 標識：讀取 模擬標識（固定標識）：讀取
如果應用程序使用明確帳戶的模擬（即，如果模擬固定標識），如 <identity impersonate="true" username="WebUser" password="Y0urStr0ngPassw0rd$"/>，則帳戶（本例中爲 WebUser）和進程都需要讀取權限。
如果代碼基準基於通用命名約定 (UNC) 共享，則必須爲 IIS 提供的 UNC 令牌標識授予讀取權限。
如果您正在模擬但沒有使用明確憑據，如 <identity impersonate="true"/>，並且沒有使用 UNC，則在 .NET Framework 1.1 中只有進程需要訪問權限。對於 .NET Framework 1.0，必須另外配置 ACL，使其爲將被模擬的任何標識授予讀取權限（即，必須爲原呼叫方授予讀取權限）。
ASP.NET 中的信任級別
應用程序的信任級別決定 CAS 策略爲其授予的權限。這也決定了應用程序能夠訪問安全資源和執行特權操作的程度。
<trust>
使用 <trust> 元素配置應用程序的信任級別。 默認情況下，配置級別設置爲“完全”，如下所示：
<!-- level="[Full|High|Medium|Low|Minimal]" --> <trust level="Full" originUrl=""/>
這意味着應用程序被授予完全、無限制的 CAS 權限。使用這種配置，應用程序執行的資源訪問成功與否只取決於操作系統安全性。
如果將信任級別更改爲“完全”以外的級別，可能會破壞依賴於訪問資源類型和執行操作類型的現有 ASP.NET Web 應用程序。應該在每個信任級別上對應用程序進行全面徹底的測試。
有關生成使用 CAS 的部分信任 Web 應用程序的詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。有關使用信任級別提供應用程序隔離的詳細信息，請參閱模塊 20 駐留多個 ASP.NET Web 應用程序。
ASP.NET 的進程標識
ASP.NET Web 應用程序和 Web Services 在 ASP.NET 工作進程 (Aspnet_wp.exe) 的共享實例中運行。進程級別的設置（包括進程標識）使用 Machine.config 中的 <processModel> 元素進行配置。
<processModel>
ASP.NET 工作進程的標識使用 <processModel> 元素上的userName 和 password 屬性進行配置。配置進程標識時：
| • |
使用默認 ASPNET 帳戶。 |
| • |
使用最小特權自定義帳戶。 |
| • |
加密 <processModel> 憑據。 |
| • |
不將 ASP.NET 作爲 SYSTEM 運行。 |
使用默認 ASPNET 帳戶
本地 ASPNET 帳戶是默認的最小特權帳戶，專用於運行 ASP.NET Web 應用程序和 Web Services。如果可以，請通過以下默認配置使用此帳戶：
<processModel enable="true" userName="machine" password="AutoGenerate" ... />
使用最小特權自定義帳戶
如果必須使用備用標識運行 ASP.NET 工作進程，請確保將所使用的帳戶配置爲最小特權帳戶。這可以限制攻擊者設法使用進程安全上下文執行代碼所帶來的損害。
您可能決定使用備用帳戶，因爲您需要使用 Windows 身份驗證連接到遠程 Microsoft SQL Server™ 數據庫或網絡資源。請注意，可以使用本地 ASPNET 帳戶執行上述操作。有關詳細信息，請參閱本模塊後面的數據訪問。
有關 ASP.NET 進程帳戶所需的 NTFS 權限的詳細信息，請參閱本模塊後面的 ACL 和權限。
還應將以下用戶權限授予 ASP.NET 進程帳戶：
| • |
從網絡訪問此計算機 |
| • |
作爲批作業登錄。 |
| • |
作爲服務登錄。 |
| • |
拒絕本地登錄。 |
| • |
拒絕通過終端服務登錄。 |
加密 <processModel> 憑據
如果您需要使用自定義帳戶，請不要在 Machine.config 中存儲純文本憑據。應使用 Aspnet_setreg.exe 實用程序在註冊表中存儲加密的憑據。
| • |
加密 <processModel> 的憑據
|
有關詳細信息，請參閱 Microsoft 知識庫文章 329290 How To:Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings（英文）。
不要將 ASP.NET 作爲 SYSTEM 運行
不要使用 SYSTEM 帳戶運行 ASP.NET，也不要爲 ASP.NET 進程帳戶授予“作爲操作系統的一部分工作”用戶權限。此操作消除了最小特權原則，從而增大了攻擊者使用 Web 應用程序的進程安全上下文執行代碼所帶來的損害。
模擬
默認情況下，ASP.NET 應用程序不使用模擬。當應用程序訪問 Windows 資源時，將使用 ASP.NET 工作進程帳戶（默認情況下爲 ASPNET）的安全上下文。
<identity>
<identity> 元素用於啓用模擬。可以模擬：
| • |
原呼叫方（IIS 驗證過的標識） |
| • |
固定標識 |
模擬原呼叫方
要模擬原呼叫方，請使用以下配置：
<identity impersonate="true" />
模擬使用 IIS 提供的代表已驗證呼叫方的訪問令牌。這可以是匿名 Internet 用戶帳戶（例如，如果應用程序使用表單身份驗證），也可以是代表原呼叫方的 Windows 帳戶（如果應用程序使用 Windows 身份驗證）。
如果確實要啓用原呼叫方模擬，請注意以下問題：
| • |
由於數據庫連接不能被有效彙集，因此會降低應用程序的可伸縮性。 |
| • |
由於需要爲單個用戶配置後端資源上的 ACL，因此會增加管理工作量。 |
| • |
委派需要 Kerberos 身份驗證和適當配置的 Windows 2000 環境。 |
有關詳細信息，請參閱“Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication”的“How To”部分中的“How To: Implement Kerberos Delegation for Windows 2000”，其網址爲：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT05.asp（英文）。
模擬固定標識
要模擬固定標識，請使用 <identity> 元素上的 userName 和 password 屬性指定標識：
<identity impersonate="true" userName="MyServiceAccount" password="Str0ng!Passw0rd"/>
請不要以純文本形式存儲此處所示的憑據。應使用 Aspnet_setreg.exe 工具加密憑據並將其存儲在註冊表中。
| • |
加密 <identity> 的憑據
|
有關詳細信息，請參閱 Microsoft 知識庫文章 329290 How To:Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings（英文）。
作爲操作系統的一部分工作
當通過指定 userName 和 password 屬性模擬固定標識時，ASP.NET 1.0 進程帳戶在 Windows 2000 上需要具有“作爲操作系統的一部分工作”用戶權限。由於這可以有效地將 ASP.NET 進程帳戶提升爲可以訪問本地系統帳戶的特權級別，因此 ASP.NET 1.0 不推薦使用模擬固定標識。
注意：如果正在 Windows 2000 或 Windows 2003 Server 上運行 ASP.NET 1.1，則不需要此用戶權限。
NTFS 權限要求
必須爲模擬標識適當配置 NTFS 權限。有關詳細信息，請參閱本模塊後面的“ACL 和權限”。
身份驗證
<authentication> 元素配置應用程序使用的驗證模式。
<authentication>
適當的身份驗證模式取決於應用程序或 Web Services 是如何設計的。默認的 Machine.config 設置應用安全的 Windows 身份驗證默認值，如下所示：
<!-- 驗證屬性： mode="[Windows|Forms|Passport|None]" --> <authentication mode="Windows" />
表單身份驗證指南
要使用表單身份驗證，請在 <authentication> 元素上設置 mode="Forms" 。接下來，使用 <forms> 子元素配置表單身份驗證。以下代碼片斷顯示了安全的 <forms> 身份驗證元素配置：
<authentication mode="Forms"> <forms loginUrl="Restricted\login.aspx" SSL 保護文件夾中的登錄頁 protection="All" 私密性和完整性 requireSSL="true" 阻止通過 http 發送 Cookie timeout="10" 限制會話壽命 name="AppNameCookie" 每個應用程序唯一的名稱 path="/FormsAuth" 和路徑 slidingExpiration="true" > 滑動會話壽命 </forms> </authentication>
使用以下建議提高表單身份驗證的安全性：
| • |
對網站進行分區。 |
| • |
設置 protection="All"。 |
| • |
使用小 Cookie 超時值。 |
| • |
考慮使用固定的有效期. |
| • |
對錶單身份驗證使用 SSL. |
| • |
如果不使用 SSL，請設置 set slidingExpiration = "false"。 |
| • |
不要在生產服務器上使用 <credentials> 元素。 |
| • |
配置 <machineKey> 元素。 |
| • |
使用唯一的 Cookie 名稱和路徑。 |
對網站進行分區
可以將網站的公共訪問區和受限制訪問區分開。將只允許通過身份驗證的用戶訪問的應用程序登錄頁和其他頁面以及資源放在一個單獨的文件夾中，與公共訪問區分開。通過在 IIS 中配置子文件夾要求 SSL 訪問權限來保護受限制的子文件夾，然後使用 <authorization> 元素來限制訪問並強制登錄。例如，以下 Web.config 配置允許任何人訪問當前目錄（這提供了公共訪問權限），但阻止未經授權的用戶訪問受限制的子文件夾。任何訪問嘗試都會強制表單登錄。
<system.web> <!-- 虛擬目錄根文件夾中包含普通頁面。 未經過身份驗證的用戶可以查看這些頁面，並且無需 使用 SSL 進行保護。 --> <authorization> <allow users="*" /> </authorization> </system.web> <!-受限制文件夾只能用於驗證和 SSL 訪問。 --> <location path="Restricted" > <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </location>
有關其他編程注意事項的信息（例如，如何在受限制頁面和非限制頁之間導航），請參閱模塊 10 生成 ASP.NET 網頁和控件中的“表單身份驗證”。
Set Protection="All"
此設置可以確保加密表單身份驗證 Cookie，以提供私密性和完整性。用於 Cookie 加密的密鑰和算法是在 <machineKey> 元素上指定的。
加密和完整性檢查可防止 Cookie 篡改，但如果攻擊者設法捕獲 Cookie，這並不能降低 Cookie 重播攻擊的風險。還可以使用 SSL 通過網絡監視軟件來阻止攻擊者捕獲 Cookie。儘管使用 SSL，Cookie 仍會被跨站點腳本 (XSS) 攻擊竊取。應用程序必須採取充分的預防措施以及適當的輸入驗證策略來降低此風險。
使用小 Cookie 超時值
可以使用小超時值限制會話壽命，從而降低窗口遭受 Cookie 重播攻擊的風險。
考慮使用固定的有效期
考慮在 <forms> 元素上設置 slidingExpiration="false"，使 Cookie 的截止日期固定，而不是在每個 Web 請求之後重置有效期。如果未使用 SSL 保護 Cookie，這一點很重要。
注意 .NET Framework 1.1 中提供此功能。
將 SSL 用於表單身份驗證
可以使用 SSL 保護憑據和身份驗證 Cookie。SSL 可阻止攻擊者捕獲用於嚮應用程序證明您的身份的憑據或表單身份驗證 Cookie。竊取身份驗證 Cookie 是竊取登錄。
設置 requireSSL="true"。這將設置 Cookie 中的 Secure 屬性，該屬性可確保不通過 HTTP 鏈接將 Cookie 從瀏覽器傳送到服務器。要求使用 HTTPS (SSL)。
注意 這是 .NET Framework 1.1 的設置。它採用明確的編程，在基於 1.0 版本構建的應用程序中設置 Cookie 的 Secure 屬性。有關詳細信息和示例代碼，請參閱模塊 10 生成安全的 ASP.NET 網頁和控件。
如果不使用 SSL，請設置 slidingExpiration = "false"
通過將 slidingExpiration 設置爲 false，可以將 Cookie 的超時期限固定爲自初始創建 Cookie 之後的某段時間（以分鐘表示）。否則，應該針對每個 Web 服務器請求更新超時時間。如果 Cookie 被捕獲，它將爲攻擊者提供足夠的時間，使其作爲已通過身份驗證的用戶來訪問您的應用程序。
注意 在 .NET Framework 1.1 中提供了此項功能。
不要在生產服務器上使用 <credentials> 元素
可以在 XML 配置文件中存儲用戶憑據，以支持快速開發和有限測試。請不要使用實際的最終用戶憑據。最終用戶憑據不應存儲在生產服務器上的配置文件中。生產應用程序應該實現自定義用戶憑據存儲，例如，在 SQL Server 數據庫中。
配置 MachineKey
<machineKey> 元素定義了用於加密表單身份驗證 Cookie 的加密算法。此元素也可用於維護加密密鑰。有關詳細信息，請參閱本模塊的計算機密鑰部分。
使用唯一的 Cookie 名稱和路徑
唯一的 name 和 path 屬性值。確保名稱具有唯一性，可以防止在同一服務器上駐留多個應用程序時出現問題。
授權
除非用戶具有明確的資源訪問權限，如特殊的網頁、資源文件、目錄等，否則配置在默認情況下應該拒絕訪問。ASP.NET 提供了兩個可配置的網關守衛，可用來控制對受限制資源的訪問。分別爲：
| • |
文件授權。此網關守衛由 ASP.NET |
| • |
URL 授權。此網關守衛由 ASP.NET |
文件授權
只有使用 Windows 身份驗證並具有以下配置的應用程序纔可以使用此網關守衛：
<authentication mode="Windows"/>
使用 Windows 身份驗證時，此網關守衛會自動有效，而無需進行模擬。要配置網關守衛，請在文件和文件夾上配置 Windows ACL。請注意，網關守衛只控制對由 IIS 映射到以下 ASP.NET ISAPI 擴展的文件類型的訪問：Aspnet_isapi.dll。
URL 授權
任何應用程序都可使用此網關守衛。它是使用 <authorization> 元素進行配置的，這些元素可以控制哪些用戶和用戶組有權訪問應用程序。Machine.config 中的默認元素如下所示：
<authorization> <!-- 允許/拒絕屬性： users="[*|?|name]" * - All users ? - Anonymous users [name] - Named user roles="[name]" --> <allow users="*"/> </authorization>
URL 授權說明
以下說明有助於您成功配置 URL 授權：
| • |
Web.config 中的授權設置通常應用於當前目錄及其所有子目錄中的所有文件，除非子目錄中包含其自身的具有 <authorization> 元素的 Web.config。在這種情況下，子目錄中的設置會覆蓋父目錄的設置。 |
| • |
URL 授權僅應用於由 IIS 映射到 ASP.NET ISAPI 擴展的文件類型：Aspnet_isapi.dll。 |
| • |
當應用程序使用 Windows 身份驗證時，則爲 Windows 用戶和組帳戶授予訪問權限。用戶名採取“authority\WindowsUserName”的格式，而角色名採取“authority\WindowsGroupName”的格式，此處的“authority”可以是域名或本機名，具體取決於帳戶類型。 許多人們熟知的帳戶都以“BUILTIN”字符串表示。例如，本地管理員組表示爲“BUILTIN\Administrators”。本地用戶組表示爲“BUILTIN\Users”。 注意 對於 .NET Framework 1.0，機構名和組名是區分大小寫的。組名必須與出現在 Windows 中的組名完全匹配。 |
| • |
當應用程序使用表單身份驗證時，則爲在自定義用戶存儲中維護的自定義用戶和角色授權。例如，如果使用表單對訪問數據庫的用戶進行身份驗證，則根據從數據庫中檢索的角色進行授權。 |
| • |
可以使用 <location> 標記將授權設置應用於單個文件或目錄。以下示例顯示如何將授權應用於特定文件 (page.aspx)： <location path="page.aspx" />
<authorization>
<allow users="DomainName\Bob, DomainName\Mary" />
<deny users="*" />
</authorization>
</location>
|
會話狀態
依賴於每個用戶會話狀態的應用程序可以在下列位置存儲會話狀態：
| • |
在 ASP.NET 工作進程中 |
| • |
在進程外狀態服務（可以在 Web 服務器或遠程服務器上運行）中 |
| • |
在 SQL Server 數據存儲中 |
<sessionState>
相關位置與連接詳細信息一起存儲在 Machine.config 的 <sessionState> 元素中。默認設置如下：
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="10" sqlConnectionString="data source=127.0.0.1;Integrated Security=SSPI" cookieless="false" timeout="20"/>
注意 如果不在 Web 服務器上使用 ASP.NET 狀態服務，可以使用 MMC 服務管理單元來禁用該服務。
確保 SQL Server 會話狀態存儲區的安全
如果使用 SQL Server 會話狀態存儲，以下建議有助於確保會話狀態的安全：
| • |
對數據庫使用 Windows 身份驗證 |
| • |
加密 sqlConnectionString |
| • |
限制數據庫中的應用程序登錄 |
| • |
確保通道安全 |
有關設置 SQL Server 會話狀態存儲數據庫的詳細信息，請參閱 Microsoft 知識庫文章 311209 How To:Configure ASP.NET for Persistent SQL Server Session State Management（英文）。
對數據庫使用 Windows 身份驗證
如果使用 mode="SQLServer"，可使用 Windows 身份驗證連接到狀態數據庫，並使用最小特權帳戶，如本地 ASPNET 帳戶的副本。這意味着您可以使用受信任連接，而不必在連接字符串中提供憑據，因此憑據不會通過網絡傳送到數據庫。
加密 sqlConnectionString
可以使用 Aspnet_setreg.exe 工具加密 sqlConnectionString 屬性值。如果使用 SQL 身份驗證連接到狀態數據庫，這一點尤其重要，因爲憑據在連接字符串中，但在使用 Windows 身份驗證時同樣建議使用上述加密。
| • |
加密 sqlConnectionString
|
限制數據庫中的應用程序登錄
應該對數據庫中的應用程序登錄進行限制，以使應用程序只能訪問所需的狀態表和 ASP.NET 用於查詢數據庫的存儲過程。
| • |
限制狀態數據庫中的應用程序登錄
|
確保通道安全
要保護通過網絡在 Web 服務器和遠程狀態存儲之間傳輸的敏感會話狀態，應使用 IPSec 或 SSL 確保到兩個服務器的通道的安全。這爲整個網絡間的會話狀態數據提供了私密性和完整性。如果使用 SSL，必須在數據庫服務器上安裝服務器證書。有關在 SQL Server 上使用 SSL 的詳細信息，請參閱模塊 18 保證數據庫服務器的安全。
確保進程外狀態服務的安全
如果使用 mode=StateServer，以下建議有助於確保會話狀態的安全：
| • |
使用最小特權帳戶運行狀態服務 |
| • |
確保通道安全 |
| • |
考慮更改默認端口 |
| • |
加密狀態連接字符串 |
使用最小特權帳戶運行狀態服務
默認情況下將使用 ASPNET 本地最小特權帳戶運行狀態服務。無需更改此配置。
確保通道安全
如果狀態服務位於遠程服務器上，應使用 IPSec 確保到遠程狀態存儲的通道的安全，以確保用戶狀態保持私密性，並且不會被修改。
考慮更改默認端口
ASP.NET 狀態服務在端口 42424 上偵聽。爲了避免使用此衆所周知的默認端口，可以通過編輯以下註冊表項來更改端口：
HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters
端口號由名爲 Port 的值定義。如果更改了註冊表中的端口號，例如，改爲 45678，必須同時更改 <sessionState> 元素中的連接字符串，如下所示：
stateConnectionString="tcpip=127.0.0.1:45678"
對 stateConnectionString 進行加密
可以對 stateConnectionString 屬性值進行加密，以隱藏狀態存儲的 IP 地址和端口號。使用 Aspnet_setreg.exe 工具。
| • |
對 stateConnectionString 進行加密
|
視圖狀態
如果應用程序使用視圖狀態，一定要使用消息驗證代碼 (MAC) 提供保護，以確保不會在客戶端上修改該視圖狀態。可以使用 Machine.config 中的 <pages> 元素，爲計算機上的所有應用程序啓用或禁用視圖狀態和 MAC 保護。
<pages>
默認情況下， Machine.config 中的 <pages> 元素上的 enableViewStateMac 屬性可以確保通過 MAC 保護視圖狀態。
<pages buffer="true" enableSessionState="true" enableViewState="true" enableViewStateMac="true" autoEventWireup="true" validateRequest="true"/>
如果使用視圖狀態，應確保將 enableViewStateMac 設置爲 true。<machineKey> 元素定義保護視圖狀態所使用的算法。
計算機密鑰
<machineKey> 元素用於指定保護表單身份驗證 Cookie 和頁面級視圖狀態所使用的加密密鑰、驗證密鑰和算法。以下代碼示例顯示了 Machine.config 中的默認設置：
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>
在配置 <machineKey> 時應考慮以下建議：
| • |
對多個應用程序使用唯一的加密密鑰 |
| • |
設置 validation="SHA1" |
| • |
手動爲 Web 場生成密鑰 |
對多個應用程序使用唯一的加密密鑰
如果在一個 Web 服務器上駐留多個應用程序，應該對計算機上的每個應用程序使用唯一的密鑰，而不是對所有應用程序使用一個密鑰。這樣可以避免在駐留環境中，一個應用程序可以欺騙視圖狀態或加密的表單身份驗證 Cookie。
還應使用 IsolateApps 設置。這是 .NET Framework 1.1 中的新設置，用於指示 ASP.NET 自動生成加密密鑰，並使每個應用程序的密鑰是唯一的。
設置 validation="SHA1"
validation 屬性指定頁面級視圖狀態的完整性檢查所使用的算法。可能的值爲“SHA1”、“MD5”和“3DES”。
如果在 <forms> 元素上使用了 protection="All"，將對錶單身份驗證 Cookie 進行加密，同時還可以確保完整性。無論 validation 屬性如何設置，表單身份驗證均使用 TripleDES (3DES) 爲 Cookie 加密。
注意：表單身份驗證 Cookie 加密與 validationkey 設置無關，該密鑰基於 decryptionKey 屬性。
如果在 <machineKey> 上設置了 validation="SHA1"，將使用 SHA1 算法檢查頁面級視圖狀態的完整性，同時假定 <pages> 元素配置爲視圖狀態 MAC。有關詳細信息，請參閱本模塊前面的視圖狀態。
也可以將 validation 屬性設置爲 MD5。應該使用 SHA1，因爲此算法生成的哈希值比 MD5 要大，因此更安全。
如果在 <machineKey> 上設置了 validation="3DES"，將使用 3DES 算法爲頁面級視圖狀態加密（同時還檢查完整性），即使 <pages> 元素配置爲視圖狀態 MAC。
手動爲 Web 場生成密鑰
在 Web 場中，必須設置明確的密鑰值，並在 Web 場中的所有計算機上使用相同的密鑰值。請參閱本模塊後面的 Web 場注意事項。
調試
<compilation> 元素控制用於動態頁面編譯的編譯器設置，該編譯器在客戶端請求網頁（.aspx 文件）或 Web Services（.asmx 文件）時啓動。不要在生產服務器上使用調試內部版本，這一點非常重要，因爲攻擊者可能會利用調試信息，並且可能會泄漏源代碼的詳細信息。
<compilation>
此元素控制編譯進程。請確保在生產服務器上禁用調試編譯。設置 debug="false"，如下所示：
<compilation debug="false" explicit="true" defaultLanguage="vb" />
默認情況下，將在以下目錄中創建和編譯臨時文件：
%winnt%\Microsoft.NET\Framework\{版本}\Temporary ASP.NET Files
可以使用 tempDirectory 屬性指定每個應用程序的位置，但此屬性在安全方面沒有優勢。
注意 在 <processModel> 元素上指定的 ASP.NET 進程標識要求對臨時編譯目錄具有完全控制訪問權限。
請確保不要在生產服務器上將調試文件（擴展名爲 .pdb）和程序集存儲在一起。
跟蹤
生產服務器上不應啓用跟蹤，因爲系統級的跟蹤信息可能會爲攻擊者瞭解應用程序並發現弱點提供很大的幫助。
<trace>
可以使用 <trace> 元素配置跟蹤。在生產服務器上設置 enabled="false"，如下所示：
<trace enabled="false" localOnly="true" pageOutput="false" requestLimit="10" traceMode="SortByTime"/>
如果確實需要跟蹤活動應用程序的問題，最好在測試環境中模擬問題，或者啓用跟蹤並設置 localOnly="true"（如果需要），以防止將跟蹤詳細信息返回到遠程客戶端。
異常管理
不允許將異常詳細信息從 Web 應用程序返回到客戶端。惡意用戶可能會利用系統級的診斷信息來了解應用程序，並發現以後攻擊時可以利用的弱點。
<customErrors>
<customErrors> 元素可用於配置自定義的一般錯誤消息，在應用程序發生異常時應將該消息返回到客戶端。錯誤頁面應包括相應的一般錯誤消息，並且可以包含額外的支持詳細信息。使用此元素還可以根據異常情況返回不同的錯誤頁面。
請確保將 mode 屬性設置爲 On，並且指定了默認的重定向頁面，如下所示：
<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
通過 defaultRedirect 屬性，可以使用應用程序的自定義錯誤頁面，例如，其中可能包括支持聯繫人的詳細信息。
注意 不要使用 mode="Off"，因爲這樣可能會將包含系統級信息的詳細錯誤頁面返回到客戶端。
如果希望不同的錯誤類型返回單獨的錯誤頁面，可使用一個或多個 <error> 元素，如下所示。在本示例中，“404 (not found)”錯誤被重定向到一個頁面，“500 (internal system errors)”被定向到另一個頁面，而所有其他錯誤都被定向到 defaultRedirect 屬性上指定的頁面。
<customErrors mode="On" defaultRedirect="YourErrorPage.htm"> <error statusCode="404" redirect="YourNotFoundPage.htm"/> <error statusCode="500" redirect="YourInternalErrorPage.htm"/> </customErrors>
遠程處理
不要在訪問 Internet 的 Web 服務器上公開 .NET 遠程處理終結點。要禁用遠程處理，可通過將對 .rem 和 .soap 文件擴展名的請求映射到 HttpForbiddenHandler，以禁用對這些擴展名的請求。在 <httpHandlers> 下使用以下元素：
<httpHandlers> <add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/> <add verb="*" path="*.soap" type="System.Web.HttpForbiddenHandler"/> . . . </httpHandlers>
注意 這不會阻止 Web 服務器上的 Web 應用程序使用遠程處理基礎結構連接下游對象。不過，它會阻止客戶端連接到 Web 服務器上的對象。
Web Services
可以使用 <webServices> 元素配置 Web Services。建立安全的 Web Services 配置：
| • |
禁用不需要的 Web Services |
| • |
禁用不使用的協議 |
| • |
禁止自動生成 WSDL |
禁用不需要的 Web Services
如果不使用 Web Services，可通過將對 .asmx（Web Services）文件擴展名的請求映射到 Machine.config 中的 HttpForbiddenHandler 來禁用 Web Services，如下所示：
<httpHandlers> <add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/> . . . </httpHandlers>
禁用不使用的協議
<protocols> 元素可以定義 Web Services 支持的協議。默認情況下，.NET Framework 1.1 上禁用 HttpPost 和 HttpGet，如下所示：
<webServices> <protocols> <add name="HttpSoap1.2"/> <add name="HttpSoap"/> <!-- <add name="HttpPost"/> --> <!-- <add name="HttpGet"/> --> <add name="HttpPostLocalhost"/> <add name="Documentation"/> </protocols> </webServices>
通過禁用不必要的協議（包括 HttpPost 和 HttpGet），可以減小受攻擊面。例如，外部攻擊者可能會在電子郵件中嵌入惡意鏈接，從而使用最終用戶的安全上下文執行內部 Web Services。禁用 HttpGet 協議是一個有效的對策。這在許多方面與 XSS 攻擊類似。此攻擊的不同之處在於，它在公共訪問網頁上使用 <img src="..."/> 標記將 GET 調用嵌入 Intranet Web Services 中。這兩種攻擊都允許外部用戶調用內部 Web Services。禁用協議可以降低風險。
如果生產服務器提供可以公共搜索的 Web Services，則必須啓用 HttpGet 和 HttpPost，以便可以通過這些協議搜索該服務。
禁止自動生成 WSDL
文檔協議用於動態生成 Web Services 描述語言 (WSDL)。WSDL 描述 Web Services 的特性，如該服務的方法簽名和所支持的協議。客戶端使用這些信息構建相應格式的消息。默認情況下，Web Services 會公開 WSDL，允許任何可以通過 Internet 連接到 Web 服務器的用戶使用。
有時，可能需要手動將 WSDL 文件分發給合作伙伴，以禁止公共訪問。通過這種方法，開發小組可以分別將每個 Web Services 的 .wsdl 文件分發給業務組。然後，由業務組將其分發給需要使用 Web Services 的指定合作伙伴。
要禁用文檔協議，應在 Machine.config 中註釋掉該協議，如下所示：
<webServices> <protocols> <add name="HttpSoap"/> <!-- <add name="Documentation"/> --> </protocols> </webServices>
禁止訪問的資源
要禁止通過 HTTP 下載受保護的資源和文件，請將這些資源和文件映射到 ASP.NET 的 HttpForbiddenHandler。
將受保護的資源映射到 HttpForbiddenHandler
HTTP 處理程序位於 Machine.config 中的 <httpHandlers> 元素下。HTTP 處理程序負責處理對特定文件擴展名的 Web 請求。不應在前端 Web 服務器上啓用遠程處理；只應在與 Internet 隔離的中間層應用程序服務器上啓用遠程處理。
| • |
以下文件擴展名在 Machine.config 中映射到 HTTP 處理程序： |
| • |
.aspx 用於 ASP.NET 頁面。 |
| • |
.rem 和 .soap 用於遠程處理。 |
| • |
.asmx 用於 Web Services。 |
| • |
.asax、.ascx、.config、.cs、.csproj、.vb、.vbproj、.webinfo、.asp、.licx、.resx 和 .resources 是受保護的資源，被映射到 System.Web.HttpForbiddenHandler。 |
對於 .NET Framework 資源，如果不使用文件擴展名，則將擴展名映射到 Machine.config 中的 System.Web.HttpForbiddenHandler，如下例所示：
<add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler" />
在本例中，.vbproj 文件擴展名映射到 System.Web.HttpForbiddenHandler。如果客戶端請求以 .vbproj 結尾的路徑，ASP.NET 將返回一條消息，表明“This type of page is not served”（無法提供此類型的頁）。
| • |
以下指南適用於處理 .NET Framework 文件擴展名： |
| • |
將不使用的擴展名映射到 HttpForbiddenHandler。如果不提供 ASP.NET 頁面，則將 .aspx 映射到 HttpForbiddenHandler。如果不使用 Web Services，則將 map .asmx 映射到 HttpForbiddenHandler。 |
| • |
在訪問 Internet 的 Web 服務器上禁用遠程處理。將訪問 Internet 的 Web 服務器上的遠程處理擴展名（.soap 和 .rem）映射到 HttpForbiddenHandler。 |
bin 目錄
ASP.NET 應用程序虛擬根目錄下的 bin 目錄包含應用程序的專用程序集，如果在開發過程中使用了代碼隱藏文件，則包括應用程序的頁面級實現。
確保 bin 目錄的安全
確保應用程序的 bin 目錄的安全，並防止無意中下載業務邏輯：
| • |
刪除 Web 權限。 |
| • |
刪除所有身份驗證設置。 |
刪除 Web 權限
使用 IIS 管理單元來確保 bin 目錄沒有讀取、寫入或目錄瀏覽權限。還要確保將“執行”權限設置爲“無”。
刪除所有身份驗證設置
使用 IIS 管理單元從 bin 目錄中刪除身份驗證設置。這會造成所有訪問均被拒絕。
事件日誌
最小特權帳戶（如 ASPNET）具有充分的權限，可以使用現有的事件來源在事件日誌中寫入記錄。但是，其權限不足以創建新的事件來源。要創建新的事件來源，必須在以下註冊表項下加入一個新條目：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>
爲了避免這個問題，如果具有管理員特權，可以在安裝時創建事件來源。可以使用 .NET 安裝程序類，通過 Windows 安裝程序（如果使用 .msi 部署）或 InstallUtil.exe 系統實用程序（如果不使用 .msi 部署）可以將該類實例化。有關如何使用事件日誌安裝程序的詳細信息，請參閱模塊 10 構建安全的 ASP.NET 網頁和控件。
如果在安裝時無法創建事件來源，必須將權限添加到以下註冊表項，併爲 ASP.NET 進程帳戶或任何模擬帳戶（如果應用程序使用模擬）授予訪問權限。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog
帳戶必須至少具有以下權限：
| • |
查詢鍵值 |
| • |
設置鍵值 |
| • |
創建子鍵 |
| • |
枚舉子鍵 |
| • |
通知 |
| • |
讀取 |
文件訪問
應用程序所訪問的任何文件在 ACL 中都必須具有訪問控制項 (ACE)，至少爲 ASP.NET 進程帳戶或模擬標識授予讀取權限。通常，ACL 在目錄上配置，然後文件繼承該設置。
除了使用 NTFS 權限限制對文件和目錄的訪問以外，還可以使用 ASP.NET 信任級別對 Web 應用程序和 Web Services 進行限制，以限制它們可以訪問文件系統的哪些區域。例如，中等信任的 Web 應用程序只能訪問其自身的虛擬目錄層次中的文件。
有關 ASP.NET CAS 策略的詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。
ACL 和權限
ASP.NET 進程帳戶和（對於特定目錄）任何模擬標識（如果應用程序使用模擬）需要以下 NTFS 權限。除了應用程序訪問應用程序特定的文件系統資源所需的權限以外，還應使用表 Table 19.3 中所示的權限。
表 19.3：ASP.NET 進程帳戶所需的 NTFS 權限
| 目錄 | 所需權限 |
|
Temporary ASP.NET Files%windir%\Microsoft.NET\Framework\{版本}Temporary ASP.NET Files |
進程帳戶和模擬標識： |
|
臨時目錄 (%temp%) |
進程帳戶 |
|
.NET Framework 目錄%windir%\Microsoft.NET\Framework\{版本} |
進程帳戶和模擬標識： |
|
.NET Framework 配置目錄%windir%\Microsoft.NET\Framework\{版本}\CONFIG |
進程帳戶和模擬標識： |
|
網站根目錄 |
進程帳戶： |
|
系統根目錄 |
進程帳戶： |
|
全局程序集高速緩存 |
進程帳戶和模擬標識： |
|
內容目錄 |
進程帳戶： |
註冊表
應用程序所訪問的任何註冊表項在 ACL 中都必須有 ACE，至少爲 ASP.NET 進程帳戶或模擬標識授予讀取權限。
數據訪問
要從 ASP.NET 應用程序使用 Windows 身份驗證訪問遠程數據庫，可以使用以下方法：
| • |
使用默認的 ASP.NET 進程帳戶。通過在數據庫服務器上創建相同用戶名和密碼的鏡像帳戶，可以使用默認的 ASP.NET 進程帳戶。在 Windows 2000 上，默認的進程帳戶爲 ASPNET。在 Windows Server 2003 上，默認的進程帳戶爲 NetworkService。 使用本地帳戶的缺點在於，如果可以轉儲 SAM 數據庫（需要管理特權），則可以訪問憑據。主要優點在於，本地帳戶可以按特定服務器劃定範圍，這在使用域帳戶時很難實現。 |
| • |
使用最小特權域帳戶運行 ASP.NET。這種方法可以簡化管理，這意味着不需要同步鏡像帳戶的密碼。如果 Web 服務器和數據庫服務器在獨立的非信任域中，或者防火牆將兩個服務器隔開，而防火牆不允許 Windows 身份驗證使用所需的端口，則不能使用該方法。 |
| • |
模擬匿名 Web 帳戶。 在 Windows Server 2003 上，可以在獨立的工作進程中運行多個應用程序，使用 IIS 6.0 應用程序池併爲每個應用程序池配置獨立的標識。 |
爲 ASP.NET 應用程序配置數據訪問權限
無論使用哪種方法，均應限制數據庫中的應用程序帳戶。要進行此操作，請爲帳戶創建 SQL Server 登錄，併爲其授予對所需數據庫的訪問權限，然後限制其權限，使它只能訪問所需的最少的數據庫對象。理想情況下，應限制權限，使登錄只能訪問應用程序或 Web Services 所使用的存儲過程。
以下過程假定使用的是鏡像本地帳戶，但對域帳戶可以使用相同的方法來限制帳戶在數據庫中的能力。
| • |
爲 ASP.NET 應用程序配置數據庫訪問權限
|
UNC 共享
ASP.NET 應用程序可以通過兩種主要方法來使用 UNC 共享：
| • |
訪問 UNC 共享上的文件 |
| • |
在 UNC 共享上駐留應用程序 |
訪問 UNC 共享上的文件
如果應用程序訪問 UNC 共享上的文件，ASP.NET 進程帳戶或任何模擬標識必須具有 ACL 定義的對共享和基礎目錄或文件的相應訪問權限。
如果使用本地 ASPNET 進程帳戶，由於此帳戶沒有網絡標識，因此必須使用相應的用戶名和密碼在遠程服務器上創建鏡像帳戶，或必須創建有權訪問兩個服務器的最小特權域帳戶。在 Windows Server 2003 上，用於運行 ASP.NET Web 應用程序的 NetworkService 帳戶可以通過網絡進行身份驗證，因此您只需要爲計算機帳戶授予訪問權限。
在 UNC 共享上駐留應用程序
可以使用 IIS 配置虛擬目錄，以指向其他計算機上的 UNC 共享，例如 \\remoteserver\appname。這樣做時，IIS 會提示您提供帳戶憑據，用於與遠程計算機建立連接。
注意：帳戶憑據以加密的格式存儲在 IIS 元數據庫中，但是可以通過 API 獲得。應確保使用的是最小特權帳戶。有關詳細信息，請參閱 Microsoft 知識庫文章 280383 IIS Security Recommendations When You Use a UNC Share and Username and Password Credentials（英文）。
如果應用程序駐留在 UNC 共享上，除非啓用了模擬，並使用固定的模擬標識，否則 ASP.NET 將模擬 IIS 提供的 UNC 令牌（通過爲 IIS 提供的帳戶憑據創建）訪問該共享，如以下配置中所示：
<identity impersonate="true" userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>
如果通過 username 和 password 屬性提供了固定的模擬帳戶，ASP.NET 將使用該帳戶而不是使用 IIS UNC 令牌來訪問共享。應用程序訪問任何資源時，也將使用固定的模擬帳戶。
注意 在上例中，已使用 Aspnet_setreg.exe 將加密的帳戶憑據存儲在註冊表中。
如果使用以下配置啓用了原呼叫方（通過 IIS 身份驗證的標識）模擬，儘管應用程序訪問任何資源時都將使用模擬令牌，但 ASP.NET 仍將使用 UNC 提供的令牌來訪問共享上的應用程序文件。
<identity impersonate="true" />
注意：用於 UNC 共享的帳戶還必須可以讀取 Machine.config。
代碼訪問安全性注意事項
代碼訪問安全性策略爲 UNC 共享上的應用程序授予 Intranet 權限集。Intranet 權限集不包含 ASP.NET Web 應用程序運行時所需的 AspNetHostingPermission，因此，如果不明確修改策略，應用程序將無法運行。
可以使用以下兩種方法：
| • |
爲駐留應用程序的 UNC 共享授予完全信任級別。 |
| • |
配置代碼訪問安全性策略，爲代碼授予 AspNetHostingPermission 及其可能需要的任何其他權限（根據代碼所訪問的資源類型和所執行的操作）。 有關 ASP.NET 代碼訪問安全性策略以及如何對特權代碼進行沙盒處理的詳細信息，請參閱模塊 9 ASP.NET 代碼訪問安全性。 注意 配置策略時，應該爲共享而不是區域授予信任級別（通過使用文件位置）。這樣可以更加細化，因爲不會影響到特定區域中的所有應用程序。 |
COM/DCOM 資源
應用程序在調用基於 COM 的資源（如服務型組件）時，將使用進程標識或模擬標識。客戶端的身份驗證和模擬級別是使用 Machine.config 中 <processModel> 元素上的 comAuthenticationLevel 和 comImpersonation 級別屬性進行配置的。
有關詳細信息和建議，請參閱模塊 17 確保應用程序服務器的安全中的“企業服務注意事項”。
拒絕服務注意事項
ASP.NET 的以下功能可以幫助您應對針對 ASP.NET 應用程序的拒絕服務攻擊：
| • |
默認情況下，POST 請求限於 4 MB。 |
| • |
檢查客戶端，以確保在請求進入工作隊列之前客戶端仍處於連接狀態。這樣可以防止攻擊者在發送多個請求後斷開客戶端。 |
| • |
在配置的限制時間後，請求執行操作超時。 |
<httpRuntime>
配置值保留在 Machine.config 中的 <httpRuntime> 元素上。以下代碼示例顯示了 1.1 版的 Machine.config 中的默認設置：
<httpRuntime executionTimeout="90" maxRequestLength="4096" useFullyQualifiedRedirectUrl="false" minFreeThreads="8" minLocalRequestFreeThreads="4" appRequestQueueLimit="100" enableVersionHeader="true"/>
可能需要減小 maxRequestLength 屬性的值，以防止用戶上載很大的文件。允許的最大值爲 4 MB。在 Open Hack 競賽中，maxRequestLength 限於 1/2 MB，如下例所示：
<system.web> <!-- 1/2 MB ×î´ó POST ³¤¶È --> <httpRuntime maxRequestLength="512"/> </system.web>
注意 ASP.NET 不能解決數據包級的攻擊。必須通過加強 TCP/IP 堆棧來解決數據包級的攻擊。有關如何配置 TCP/IP 堆棧的詳細信息，請參閱本指南“如何”部分中的如何：強化 TCP/IP 堆棧安全。
Web 場注意事項
如果 ASP.NET Web 應用程序在 Web 場中運行，不能保證由同一個 Web 服務器處理來自同一客戶端的連續請求。這會影響到：
| • |
會話狀態 |
| • |
加密和驗證 |
| • |
DPAPI |
會話狀態
爲了避免服務器的相互影響，可以將進程外的 ASP.NET 會話狀態保留在 ASP.NET SQL Server 狀態數據庫中，或保留在遠程計算機上運行的進程外狀態服務中。有關如何確保遠程狀態存儲中會話狀態的安全的詳細信息，請參與本文檔前面的會話狀態部分。
加密和驗證
用於加密和驗證表單身份驗證 Cookie 和視圖狀態的密鑰在 Web 場中的所有服務器上必須相同。<machineKey> 元素上的 AutoGenerate 設置必須使用常用的密鑰值替換。
有關如何生成和配置密鑰的詳細信息，請參閱 Microsoft 知識庫文章 312906 How To:Create Keys by Using Visual C# .NET for Use in Forms Authentication（英文）。
DPAPI
爲了對數據加密，開發人員有時會使用 DPAPI。如果使用 DPAPI 和計算機密鑰存儲機密，加密的字符串將針對指定的計算機，而不能在 Web 場或羣集中的各個計算機之間複製加密數據。
如果使用 DPAPI 和用戶密鑰，可以在任意具有漫遊用戶配置文件的計算機上對數據進行解密。但是不建議這樣做，因爲網絡上可以使用用來加密數據的帳戶來執行代碼的任何計算機將都可以對數據進行解密。
DPAPI 非常適合存儲 Web 服務器上的配置機密，如數據庫連接字符串。如果加密數據存儲在遠程服務器上（例如，在數據庫中），應使用其他加密技術。有關如何將加密數據存儲在數據庫中的詳細信息，請參閱模塊 14 構建安全的數據訪問。
安全 ASP.NET 應用程序的快照
以下快照視圖顯示了安全 ASP.NET 應用程序的屬性，使您可以方便快捷地將設置與自己的配置進行比較。
表 19.4：安全 ASP.NET 應用程序配置的快照
| 組件 | 特性 |
|
進程標識 |
SP.NET 工作進程作爲 ASPNET 運行： <processModel username="machine"
password="AutoGenerate" />
自定義帳戶（如果使用）是最小特權帳戶。 <processModel
userName="registry:HKLM\SOFTWARE\YourApp\
process\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourApp\
process\ASPNET_SETREG,password"/>
|
|
模擬 |
模擬標識在註冊表中加密： <identity impersonate="true"
userName="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,password"/>
|
|
身份驗證 |
網站分爲公共訪問區和受限制訪問區。 <forms loginUrl="Restricted\login.aspx"
protection="All"
requireSSL="true"
timeout="10"
name="AppNameCookie"
path="/FormsAuth"
slidingExpiration="true" />
對身份驗證 Cookie 進行加密和完整性檢查。 |
|
授權 |
ACL 是在 ASP.NET 資源上配置的。 |
|
會話狀態 |
禁用不需要的 ASP.NET 狀態服務。
<sessionState mode="Off " />
與遠程狀態存儲的通信通道已根據需要進行加密。 |
|
視圖狀態 |
視圖狀態 MAC 在 Machine.config 中的 <pages> 元素上啓用。 |
|
計算機密鑰 |
validation 屬性設置爲 SHA1。
<machineKey validationKey="AutoGenerate,IsolateApps"
decryptionKey="AutoGenerate,IsolateApps"
validation="SHA1"/>
|
|
禁止訪問的資源 |
受保護的資源映射到 System.Web.HttpForbiddenHandler。 |
|
調試 |
禁用調試內部版本：
<compilation debug="false" . . .
|
|
跟蹤 |
禁用跟蹤。
<trace enabled='false' localOnly='true . . .
|
|
異常管理 |
啓用自定義錯誤。 <customErrors mode="On"
defaultRedirect="YourErrorPage.htm" />
|
|
遠程處理 |
在訪問 Internet 的 Web 服務器上禁用遠程處理： <httpHandlers>
<add verb="*" path="*.soap"
type="System.Web.HttpForbiddenHandler"/>
<add verb="*" path="*.rem"
type="System.Web.HttpForbiddenHandler"/>
. . .
</httpHandlers>
|
|
Web Services |
禁用不需要的 Web Services： <httpHandlers>
<add verb="*" path="*.asmx"
type="System.Web.HttpForbiddenHandler"/>
. . .
</httpHandlers>
禁用不需要的協議： <webServices>
<protocols>
<!-- <add name="HttpPost"/> -->
<!-- <add name="HttpGet"/> -->....
禁用文檔協議，以防止自動生成 WSDL： <webServices>
<protocols>
<!--<add name="Documentation"/>-->
. . .
|
|
bin 目錄 |
bin 目錄受到保護。 |
小結
本模塊通過重點介紹帳戶、服務、協議、文件和目錄等配置類別，以及在 Machine.config 和 Web.config 文件中維護的配置數據，說明如何確保 ASP.NET Web 應用程序或 Web Services 的安全。本模塊還說明如何確保 ASP.NET Web 應用程序和 Web 服務器所依靠的不同功能區的安全，這些功能區包括身份驗證、授權、會話狀態和數據訪問。
相關檢查表，請參閱本指南“檢查表”部分中的檢查表：保護 ASP.NET 的安全。
其他資源
有關詳細信息，請參閱以下資源和文章：
| • |
可以在 http://microsoft.com/downloads/details.aspx?FamilyId=06255A94-2635-4D29-A90C-28B282993A41&displaylang=en 下載 Web Services Enhancements (WSE) 1.0 SP1 for Microsoft .NET（英文）。 |
| • |
Microsoft 知識庫文章 329290 How To:Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings（英文）。 |
| • |
Microsoft 知識庫文章 311209 How To:Configure ASP.NET for Persistent SQL Server Session State Management（英文）。 |
| • |
Microsoft 知識庫文章 312906 How To:Create Keys by Using Visual C# .NET for Use in Forms Authentication（英文）。 |
| • |
“How To:Implement Kerberos Delegation for Windows 2000”，該內容在“Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications:Authentication, Authorization, and Secure Communication”的“How To”部分，其網址爲：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT05.asp（英文）。 |
| • |
有關 Open Hack 競賽的安全注意事項的詳細信息，請參閱 MSDN 文章構建和配置更安全的網站。 |
轉載說明
作者：來自微軟TechNet相關文章
網址：本文引用自http://www.microsoft.com/china/technet/security/guidance/secmod92.mspx