show toc
保护 ASP.NET 应用程序的安全发布日期： 1/21/2005 | 更新日期： 1/21/2005
 本单元概要保护 ASP.NET Web 应用程序依赖于完全受到保护的网络、主机和平台基础结构。如果果真如此，攻击者将试图利用 Web 应用程序和 Web 服务（它们通常侦听端口 80）中的漏洞。如果 Web 应用程序没有有效配置，攻击者就能够获取访问权限并利用系统。 作为管理员，您必须审查默认的机器级配置和单独的应用程序配置，以处理和删除任何脆弱或者不安全的设置。 本单元从系统管理员的观点描述了 ASP.NET 的新功能，以及如何配置机器范围的和特定于应用程序的安全设置。还提出了一种保护 ASP.NET Web 应用程序和 Web 服务的方法，它对我们已经提出的保护网络、应用程序服务器、数据库服务器和 Web 服务器的方法是一种补充。 目标使用本单元可以：
适用范围本单元适用于下列产品和技术：
如何使用本单元本单元的注意力主要集中在 ASP.NET 应用程序的关键安全注意事项。要想充分利用本单元：
相关的指导，请阅读“寄宿多个 ASP.NET 应用程序”单元，该单元说明了如何将多个运行在同一服务器上的 Web 应用程序与关键系统资源隔离，以及将应用程序互相隔离。有关为部分信任 Web 应用程序和 Web 服务配置代码访问安全 (CAS) 策略的更多信息，请参阅“在 ASP.NET 中使用代码访问安全”单元。 本页内容方法要保护 ASP.NET 应用程序的安全，首先要有加固的操作系统和 .NET Framework 安装基础，然后应用安全应用程序配置设置，以减少应用程序的受攻击面。 这些内容包括：
须知在开始保护 Web 应用程序和 Web 服务之前，应该知道一些涉及全局的注意事项和细节。 ASP.NET 进程模型 在 Microsoft Windows 2000 上，Internet 信息服务 (IIS) 5.0 在 ASP.NET 辅助进程 (Aspnet_wp.exe) 中运行所有 Web 应用程序和 Web 服务。隔离的单位是应用程序域，每个虚拟目录都有自己的应用程序域。进程级配置设置是通过 Machine.config 中的 <processModel> 元素维护的。 在 Microsoft Windows Server™ 2003 操作系统上，IIS 6.0 应用程序池使您能够使用不同的进程隔离应用程序。有关更多信息，请参阅单元“寄宿多个 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> 元素的变化： <!--Before-->
<processModel userName="CustomAccount" password="Str0ngPassword" />
<!--After-->
<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 将向 System、Administrator 和 Creator Owner 授予完全控制权限。如果使用此工具加密 <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 应用程序不使用模拟，因为这对设计、实现和可伸缩性有负面影响。例如，使用模拟妨碍有效的中间层连接池的使用，这限制了应用程序的可伸缩性。在特定的场景例如当应用程序使用匿名用户帐户的安全上下文进行资源访问时，模拟可能非常重要。这是一个常用技术，经常在多个应用程序寄宿在同一服务器时使用。有关更多信息，请参阅单元“寄宿多个 ASP.NET 应用程序”。 HttpForbiddenHandler、Urlscan 和 404.dll 您可以用许多技术来防止访问受限资源。ASP.NET 提供了 HttpForbiddenHandler，可以将不应该通过 HTTP 下载的 ASP.NET 文件类型映射为此处理程序。映射是使用 <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 的更多信息，请参阅“保护 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 标记是区分大小写的，因此需要确保使用正确的大小写。 图 1 显示了用来配置管理员能够访问的 ASP.NET Web 应用程序的配置文件。 
图 1. ASP.NET 配置文件 Machine.Config 和 Web.Config 文件共享许多相同的配置节和 XML 元素。Machine.config 用来将机器范围的策略应用于本地计算机上运行的所有 .NET Framework 应用程序。开发人员还可以使用特定于应用程序的 Web.config 文件为单独应用程序自定义设置。 注 Windows 可执行文件，如 WinForm 应用程序，是使用配置文件配置的。这些文件的名称从应用程序可执行文件名称派生而来，例如，App.exe.config，其中的 App 是应用程序名称。 对配置文件所做的更改是动态应用的，通常不需要您重启服务器或者任何服务，除非如果更改 Machine.config 中的 <processModel> 元素，这将在本单元后面讨论。 表 1 显示了配置文件的位置。
有关 ASP.NET Web 应用程序 CAS 配置文件的更多信息，请参阅“在 ASP.NET 中使用代码访问安全”单元。 层次化策略评估 为了集中化管理，设置可以在 Machine.config 中应用。Machine.config 中的设置定义了机器范围的策略，还可以通过 <location> 元素使用 Machine.config 中的设置应用特定于应用程序的配置。开发人员可以提供应用程序配置文件以改写机器策略的各个方面。对于 ASP.NET Web 应用程序，Web.config 文件位于应用程序的虚拟根目录，也可以选择在虚拟根下的子目录。考虑如图 2 中所示的安排。 
图 2. 层次化配置 在图 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 >元素清除父级设置。 下表显示了为了应用于图 2 的 Web 请求的组合，从何处获取组合的配置设置。
<location> 元素用于三个主要目标：
<location> 标记可以用于 Machine.config 中或者 Web.config 中。对于 Machine.config，如果您指定了路径，则必须是完全限定的，包括 Web 站点名称、虚拟目录名称和可选的子目录和文件名。例如： <location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
<system.web>
. . .
</system.web>
</location>
注 当使用来自 Machine.config 的位置标记时，您必须包括 Web 站点名称。对于 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>
… machine-wide defaults
</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 文件。虽然可能从 Machine.config 使用多个 <location> 元素配置单独应用程序，但是通过不同的 Web.config 文件对部署来说更佳，而且能够使 Machine.config 文件更小。 主要要考虑的项是哪些设置应该通过机器策略强制。这取决于特定的场景如何。以下是一些常见的场景：
ACL 和权限 配置文件包含敏感数据，所以需要适当地配置 ACL 以限制访问。 Machine.config 默认时，Machine.config 使用以下 ACL 配置： Administrators: Full Control
System: Full Control
Power Users: Modify
Users: Read and Execute
LocalMachine\ASPNET (process identity): Read and Execute
注 在 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，它默认时授予 Everyone 组的成员读访问权限。要锁定特定于应用程序的 Web.config，使用以下的一个 ACL。 对于 .NET Framework 1.0 版： Administrators: Full control
System: Full control
ASP.NET process identity: Read
UNC Identity: Read
Impersonated Identity (Fixed Identity): Read
Impersonated Identity (Original Caller): Read
对于 .NET Framework 1.1 版： Administrators: Full control
System: Full control
ASP.NET process identity: Read
UNC Identity: Read
Impersonated Identity (Fixed Identity): Read
如果您的应用程序使用一个 显式帐户的模拟（也就是说，如果它们模拟一个固定标识），如 <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>元素配置应用程序的信任级。默认时，配置级设置为 Full，如下所示： <!-- level="[Full|High|Medium|Low|Minimal]" -->
<trust level="Full" originUrl=""/>
这意味着应用程序将被授予完全和无限的 CAS 权限。使用此配置，应用程序进行的任何资源访问的成败只取决于操作系统安全。 如果您将信任级更改为 Full 之外的其他级，可能破坏现有 ASP.NET Web 应用程序，具体情况取决于它们所访问的资源和它们所执行的操作的类型。应用程序应该彻底地在每个信任级进行测试。 有关构建使用 CAS 的部分信任 Web 应用程序的更多信息，请参阅“在 ASP.NET 中使用代码访问安全”单元。有关使用信任级提供应用程序隔离的更多信息，请参 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
