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

注册表

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

数据访问

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

使用默认的 ASP.NET 进程帐户。通过在数据库服务器上创建相同用户名和密码的镜像帐户，可以使用默认的 ASP.NET 进程帐户。在 Windows 2000 上，默认的进程帐户为 ASPNET。在 Windows Server 2003 上，默认的进程帐户为 NetworkService。

使用本地帐户的缺点在于，如果可以转储 SAM 数据库（需要管理特权），则可以访问凭据。主要优点在于，本地帐户可以按特定服务器划定范围，这在使用域帐户时很难实现。

使用最小特权域帐户运行 ASP.NET。这种方法可以简化管理，这意味着不需要同步镜像帐户的密码。如果 Web 服务器和数据库服务器在独立的非信任域中，或者防火墙将两个服务器隔开，而防火墙不允许 Windows 身份验证使用所需的端口，则不能使用该方法。

模拟匿名 Web 帐户。
如果使用表单或 Passport 身份验证，可以模拟匿名 Web 帐户（默认帐户为 IUSR_MACHINE），并在数据库服务器上创建镜像帐户。如果方案在同一个 Web 服务器上驻留多个 Web 应用程序，可以使用该方法。可以使用 IIS 为每个应用程序的虚拟目录配置不同的匿名帐户。

在 Windows Server 2003 上，可以在独立的工作进程中运行多个应用程序，使用 IIS 6.0 应用程序池并为每个应用程序池配置独立的标识。

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

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

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

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

1.

使用计算机管理工具将 Web 服务器上本地 ASPNET 帐户的密码更改为已知的强密码。
为了可以在数据库服务器上创建镜像帐户，您需要执行此操作。

2.

在 Machine.config 中更改 <processModel> 元素上的 password 属性，使 ASP.NET 工作进程继续使用 ASPNET 帐户运行。使用 Aspnet_setreg.exe 将加密的凭据存储在注册表中。

3.

在数据库服务器上使用相同的名称 (ASPNET) 和强密码创建本地帐户。

4.

在数据库服务器上创建本地 Windows 组（如 ASPNETWebApp），然后将本地 ASPNET 帐户添加到该组。

5.

通过创建新登录，为 Windows 组授予访问 SQL Server 的权限，如下所示：

sp_grantlogin ''''MACHINE\ASPNETWebApp''''

注意：请使用数据库服务器的名称替换 MACHINE。

6.

为 SQL 登录授予访问数据库的权限。下面的 T-SQL 将创建与该登录关联的数据库用户 WebAppUser。

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

7.

创建用户定义的数据库角色。

USE YourDatabase
GO
sp_addrole ''''WebAppUserRole''''

8.

将数据库用户添加到新的数据库角色。

USE YourDatabase
GO
sp_addrolemember ''''WebAppUserRole'''', ''''WebAppUser''''

9.

为数据库角色配置在数据库中的权限。理想情况下，只为应用程序查询数据库时所使用的存储过程授予执行权限，而不提供直接访问表的权限。

grant execute on sprocname to WebAppUserRole

UNC 共享

ASP.NET 应用程序可以通过两种主要方法来使用 UNC 共享：

访问 UNC 共享上的文件
例如，应用程序必须访问 \\remoteserver\share\somefile.dat 等远程文件。

在 UNC 共享上驻留应用程序
应用程序的 IIS 虚拟目录映射到远程共享，例如 \\remoteserver\appname。在此方案中，由 Web 服务器处理 HTTP 请求，但应用程序的网页、资源和专用程序集位于远程共享上。

访问 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 共享授予完全信任级别。
这是最简单的管理方法，如果运行 .NET Framework 1.0，则只能使用这种方法，因为 ASP.NET 1.0 Web 应用程序需要完全信任。

配置代码访问安全性策略，为代码授予 AspNetHostingPermission 及其可能需要的任何其他权限（根据代码所访问的资源类型和所执行的操作）。
由于 ASP.NET 动态创建代码和编译页面类的方式，在配置策略时必须对 UNC 和 Temporary ASP.NET Files 目录使用代码组。默认的临时目录为 \WINNT\Microsoft.NET\Framework\{版本}\Temporary ASP.NET Files，但可以使用 <compilation> 元素的 tempDirectory 属性为每个应用程序配置该位置。

有关 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 应用程序配置的快照

Copyright ＠ 2007-2012 敏韬网(敏而好学，文韬武略--MinTao.Net)（学习笔记） Inc All Rights Reserved.
闵涛 E_mail:admin@mintao.net(欢迎提供学习资源)

鄂公网安备 42011102001154号

站长：MinTao ICP备案号：鄂ICP备11006601号-18