确保 ASP.NET 应用程序和 Web Services 的安全

	本模块内容
	目标
	适用范围
	如何使用本模块
	方法
	必备知识
	描述 Machine.Config 和 Web.Config
	Machine.Config 和 Web.Config 指南
	ASP.NET 中的信任级别
	ASP.NET 的进程标识
	模拟
	身份验证
	授权
	会话状态
	视图状态
	计算机密钥
	调试
	跟踪
	异常管理
	远程处理
	Web Services
	禁止访问的资源
	bin 目录
	事件日志
	文件访问
	ACL 和权限
	注册表
	数据访问
	UNC 共享
	COM/DCOM 资源
	拒绝服务注意事项
	Web 场注意事项
	安全 ASP.NET 应用程序的快照
	小结
	其他资源

本模块内容

安全的 ASP.NET Web 应用程序依赖于完全安全的网络、主机和平台基础结构。当上述条件满足后，攻击者将尝试利用 Web 应用程序和 Web
Services（通常在端口 80 上侦听）中的漏洞。如果未有效配置 Web 应用程序，攻击者可能会获得系统的访问权限并利用系统。

作为管理员，您必须检查默认的计算机级配置和各个应用程序配置，以处理和删除所有漏洞或不安全设置。

本模块从系统管理员的角度描述了 ASP.NET 中的新增内容，并描述了如何配置计算机范围和应用程序特定的安全设置。此外，本模块还提供了确保 ASP.NET
Web 应用程序和 Web Services 安全的方法，这种方法是为确保网络、应用程序服务器、数据库服务器和 Web 服务器安全而推荐的方法的补充。

使用本模块可以实现：

本模块适用于下列产品和技术：

本模块着重描述了 ASP.NET 应用程序的主要安全注意事项。为了充分理解本模块内容，请：

要获取相关指南，请阅读模块 20 驻留多个 ASP.NET 应用程序，本模块描述了如何将同一服务器上运行的多个 Web
应用程序与重要的系统资源隔离，以及如何将各个 Web 应用程序彼此隔离。有关配置部分信任 Web 应用程序和 Web Services 的代码访问安全性
(CAS) 策略的详细信息，请参阅模块 9 ASP.NET 代码访问安全性。

要确保 ASP.NET 应用程序的安全，应先强化操作系统和 .NET Framework
安装基准，然后应用安全的应用程序配置设置，以减小应用程序的受攻击面。

这些措施包括：

必备知识

在采取措施确保 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 允许在注册表中以加密格式存储凭据和连接字符串。此工具允许加密下列属性：

以下示例显示了运行 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（英文）。

.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：配置文件的位置

有关 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：应用配置设置

<location>

<location> 元素主要用于三个目的：

可以在 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 中的设置为服务器应用计算机级的默认值。如果要为服务器上所有应用程序强制使用特定的配置，可在 <location>
元素上使用
allowOverride=”false”，如上所述。这对驻留方案尤其适用，在驻留方案中，需要为服务器上的所有应用程序强制实施安全策略的各个方面。

对于可以基于单个应用程序配置的那些设置，通常应用程序会提供 Web.config 文件。尽管可以使用多个 <location> 元素从
Machine.config 配置单个应用程序，但单独的 Web.config 文件可以提供部署优势，并能使 Machine.config
文件变得更小。

需要考虑的主要问题是计算机策略应该强制使用哪些设置。这取决于特定的方案。一些通用方案如下所示：

<location path="" allowOverride="false"> 
<system.web>
<authentication mode="Windows"/>   
</system.web>
</location>         

<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，使其为将被模拟的任何标识授予读取权限（即，必须为原呼叫方授予读取权限）。

应用程序的信任级别决定 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 Web 应用程序和 Web Services 在 ASP.NET 工作进程 (Aspnet_wp.exe)
的共享实例中运行。进程级别的设置（包括进程标识）使用 Machine.config 中的 <processModel> 元素进行配置。

<processModel>

ASP.NET 工作进程的标识使用 <processModel> 元素上的userName 和 password
属性进行配置。配置进程标识时：

使用默认 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
实用程序在注册表中存储加密的凭据。

aspnet_setreg -k:Software\YourApp\process -u:CustomAccount :p:StrongPassword 

<processModel 
userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"  
password="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,password"/>  

有关详细信息，请参阅 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> 元素用于启用模拟。可以模拟：

模拟原呼叫方

要模拟原呼叫方，请使用以下配置：

<identity impersonate="true" />

模拟使用 IIS 提供的代表已验证呼叫方的访问令牌。这可以是匿名 Internet 用户帐户（例如，如果应用程序使用表单身份验证），也可以是代表原呼叫方的
Windows 帐户（如果应用程序使用 Windows 身份验证）。

如果确实要启用原呼叫方模拟，请注意以下问题：

有关详细信息，请参阅“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 工具加密凭据并将其存储在注册表中。

aspnet_setreg -k:Software\YourApp\identity -u:CustomAccount :p:StrongPassword 

<identity impersonate="true"
userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>

有关详细信息，请参阅 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> 

使用以下建议提高表单身份验证的安全性：

对网站进行分区

可以将网站的公共访问区和受限制访问区分开。将只允许通过身份验证的用户访问的应用程序登录页和其他页面以及资源放在一个单独的文件夹中，与公共访问区分开。通过在
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
提供了两个可配置的网关守卫，可用来控制对受限制资源的访问。分别为：

文件授权

只有使用 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 授权：

<location path="page.aspx" /> 
<authorization>   
<allow users="DomainName\Bob, DomainName\Mary" /> 
<deny users="*" /> 
</authorization>    
</location>         

依赖于每个用户会话状态的应用程序可以在下列位置存储会话状态：

<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 会话状态存储，以下建议有助于确保会话状态的安全：

有关设置 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 身份验证时同样建议使用上述加密。

aspnet_setreg -k:Software\YourApp\sessionState -c:{your connection string} 

sessionState mode="SQLServer" 
sqlConnectionString="registry:HKLM\SOFTWARE\YourApp\sessionState
\ASPNET_SETREG,sqlConnectionString" /> 

限制数据库中的应用程序登录

应该对数据库中的应用程序登录进行限制，以使应用程序只能访问所需的状态表和 ASP.NET 用于查询数据库的存储过程。

sp_grantlogin 'MACHINE\ASPNETWebApps' 

USE ASPState  
GO
sp_grantdbaccess 'MACHINE\ASPNETWebApps', 'WebAppUser' 

USE ASPState 
GO
sp_addrole 'WebAppUserRole'

USE ASPState  
GO
sp_addrolemember 'WebAppUserRole', 'WebAppUser'

grant execute on CreateTempTables to WebAppUserRole

确保通道安全

要保护通过网络在 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
工具。

aspnet_setreg -k:Software\YourApp\sessionState -d:{连接字符串}

<sessionState mode="StateServer"
sqlConnectionString="registry:HKLM\SOFTWARE\YourApp\sessionState
\ASPNET_SETREG,sqlConnectionString" ... />

如果应用程序使用视图状态，一定要使用消息验证代码 (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> 时应考虑以下建议：

对多个应用程序使用唯一的加密密钥

如果在一个 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
服务器上的对象。

可以使用 <webServices> 元素配置 Web Services。建立安全的 Web Services 配置：

禁用不需要的 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 隔离的中间层应用程序服务器上启用远程处理。

对于 .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”（无法提供此类型的页）。

ASP.NET 应用程序虚拟根目录下的 bin 目录包含应用程序的专用程序集，如果在开发过程中使用了代码隐藏文件，则包括应用程序的页面级实现。

确保 bin 目录的安全

确保应用程序的 bin 目录的安全，并防止无意中下载业务逻辑：

删除 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 代码访问安全性。

ASP.NET 进程帐户和（对于特定目录）任何模拟标识（如果应用程序使用模拟）需要以下 NTFS
权限。除了应用程序访问应用程序特定的文件系统资源所需的权限以外，还应使用表 Table 19.3 中所示的权限。

表 19.3：ASP.NET 进程帐户所需的 NTFS 权限

应用程序所访问的任何注册表项在 ACL 中都必须有 ACE，至少为 ASP.NET 进程帐户或模拟标识授予读取权限。

要从 ASP.NET 应用程序使用 Windows 身份验证访问远程数据库，可以使用以下方法：

为 ASP.NET 应用程序配置数据访问权限

无论使用哪种方法，均应限制数据库中的应用程序帐户。要进行此操作，请为帐户创建 SQL Server
登录，并为其授予对所需数据库的访问权限，然后限制其权限，使它只能访问所需的最少的数据库对象。理想情况下，应限制权限，使登录只能访问应用程序或 Web
Services 所使用的存储过程。

以下过程假定使用的是镜像本地帐户，但对域帐户可以使用相同的方法来限制帐户在数据库中的能力。

sp_grantlogin 'MACHINE\ASPNETWebApp'

USE YourDatabase
GO
sp_grantdbaccess 'MACHINE\ASPNETWebApp', 'WebAppUser'

USE YourDatabase
GO
sp_addrole 'WebAppUserRole'

USE YourDatabase
GO
sp_addrolemember 'WebAppUserRole', 'WebAppUser'

grant execute on sprocname to WebAppUserRole

ASP.NET 应用程序可以通过两种主要方法来使用 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，因此，如果不明确修改策略，应用程序将无法运行。

可以使用以下两种方法：

应用程序在调用基于 COM 的资源（如服务型组件）时，将使用进程标识或模拟标识。客户端的身份验证和模拟级别是使用 Machine.config 中
<processModel> 元素上的 comAuthenticationLevel 和 comImpersonation
级别属性进行配置的。

有关详细信息和建议，请参阅模块 17 确保应用程序服务器的安全中的“企业服务注意事项”。

ASP.NET 的以下功能可以帮助您应对针对 ASP.NET 应用程序的拒绝服务攻击：

<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 3¤?è -->
<httpRuntime maxRequestLength="512"/>
</system.web>

注意 ASP.NET 不能解决数据包级的攻击。必须通过加强 TCP/IP 堆栈来解决数据包级的攻击。有关如何配置 TCP/IP
堆栈的详细信息，请参阅本指南“如何”部分中的如何：强化 TCP/IP 堆栈安全。

如果 ASP.NET Web 应用程序在 Web 场中运行，不能保证由同一个 Web 服务器处理来自同一客户端的连续请求。这会影响到：

会话状态

为了避免服务器的相互影响，可以将进程外的 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 应用程序的属性，使您可以方便快捷地将设置与自己的配置进行比较。

表 19.4：安全 ASP.NET 应用程序配置的快照

<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" />

   
<sessionState  mode="Off " />  

  
<machineKey validationKey="AutoGenerate,IsolateApps"            
	decryptionKey="AutoGenerate,IsolateApps"           
	validation="SHA1"/>

 
<compilation debug="false" . . .

 
<trace enabled='false' localOnly='true . . .

<customErrors mode="On"
defaultRedirect="YourErrorPage.htm" /> 

<httpHandlers>
<add verb="*" path="*.soap"
	type="System.Web.HttpForbiddenHandler"/>
<add verb="*" path="*.rem"
	type="System.Web.HttpForbiddenHandler"/>
. . .	
</httpHandlers>

<httpHandlers>
<add verb="*" path="*.asmx"
type="System.Web.HttpForbiddenHandler"/>
                   . . .
</httpHandlers>

<webServices>
	<protocols>      
		<!-- <add name="HttpPost"/> -->
		<!-- <add name="HttpGet"/> -->.... 

<webServices>
	 <protocols>
	 		<!--<add name="Documentation"/>-->
. . .  

本模块通过重点介绍帐户、服务、协议、文件和目录等配置类别，以及在 Machine.config 和 Web.config
文件中维护的配置数据，说明如何确保 ASP.NET Web 应用程序或 Web Services 的安全。本模块还说明如何确保 ASP.NET Web
应用程序和 Web 服务器所依靠的不同功能区的安全，这些功能区包括身份验证、授权、会话状态和数据访问。

相关检查表，请参阅本指南“检查表”部分中的检查表：保护 ASP.NET 的安全。

有关详细信息，请参阅以下资源和文章：