本页内容

本模块内容

安全的 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（英文）。

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

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

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 帐户

本地 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