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

本模块从系统管理员的角度描述了 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 允许在注册表中以加密格式存储凭据和连接字符串。此工具允许加密下列属性：

•

•

•

以下示例显示了运行 Aspnet_setreg.exe（以确保凭据安全）前后自定义帐户的 <processModel> 元素：

<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

（每台计算机每个 .NET Framework 安装版一个

）

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Web.config

（每个应用程序有零个、一个或多个）

\inetpub\wwwroot\web.config

\inetpub\wwwroot\YourApplication\web.config

\inetpub\wwwroot\YourApplication\SubDir\web.config

Enterprisesec.config

（企业级 CAS 配置）

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Security.config

（计算机级 CAS 配置）

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Security.config

（用户级 CAS 配置）

\Documents and Settings\{user}\Application

Data\Microsoft\CLR Security Config\{version}

Web_hightrust.config

Web_mediumtrust.config

Web_lowtrust.config

Web_minimaltrust.config

（ASP.NET Web 应用程序 CAS 配置）

%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

Web.config (AppRoot v-dir)

http://Server/AppRoot/SubDir1

Machine.config

Web.config (AppRoot v-dir)

Web.config (SubDir1)

http://Server/AppRoot/SubDir2

Machine.config

Web.config (AppRoot v-dir)

http://Server/Subdir2

Machine.config

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

•

将配置设置应用于特定的应用程序文件。

•

通过在 Machine.config 中应用应用程序特定的设置进行集中管理。

•

锁定配置设置以阻止应用程序级覆盖。

可以在 Machine.config 或 Web.config 中使用 <location> 标记。对于 Machine.config，如果指定路径，必须完全限定该路径，使其包括网站名和虚拟目录名，还可以包括子目录和文件名（可选）。例如：

<system.web>

. . .

</system.web>

</location>

注意使用 Machine.config 的位置标记时，必须包括网站名。

对于 Web.config，路径相对于应用程序的虚拟目录。例如：

<system.web>

. . .

</system.web>

</location>

将配置设置应用于特定文件

使用“path”属性对特定文件应用配置设置。例如，要将授权规则应用于 Web.config 中的文件 Pagename.aspx，请使用下面的 <location> 元素：

<system.web>

</authorization>

</system.web>

</location>

在 Machine.config 中应用应用程序配置设置

还可以使用指定应用程序目录路径的 <location> 语句，在 Machine.config 中应用应用程序特定的设置。这样有利于集中管理。例如，下面的代码片段显示了如何强制使用 Windows 身份验证，以及如何阻止在特殊应用程序中使用模拟。

<system.web>

</system.web>

</location>

锁定配置设置

要阻止单个应用程序覆盖计算机级的策略配置，可将设置放入 Machine.config 的 <location> 元素中，并设置 allowOverride="false" 属性。

例如，要应用不能在应用程序级覆盖的计算机范围的策略，请使用下面的 <location> 元素：

<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 身份验证，但允许单个应用程序模拟以下配置：

<system.web>

</system.web>

</location>

•

驻留方案提供驻留服务的公司需要限制应用程序，以使它们不能访问彼此的资源，从而限制对重要系统资源的访问。要实现此目标，可以配置所有应用程序以部分信任级别运行。例如，中级信任级别限制应用程序只能访问自身虚拟目录分级结构内的文件，而限制对其他类型资源的访问。有关详细信息，请参阅模块 9 ASP.NET 代码访问安全性。要对服务器上的所有应用程序应用中级信任策略，请使用以下配置：

<system.web>

</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> 元素配置应用程序的信任级别。默认情况下，配置级别设置为“完全”，如下所示：

这意味着应用程序被授予完全、无限制的 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> 元素进行配置。

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

•

使用默认 ASPNET 帐户。

•

使用最小特权自定义帐户。

•

加密 <processModel> 凭据。

•

不将 ASP.NET 作为 SYSTEM 运行。

使用默认 ASPNET 帐户

本地 ASPNET 帐户是默认的最小特权帐户，专用于运行 ASP.NET Web 应用程序和 Web Services。如果可以，请通过以下默认配置使用此帐户：

使用最小特权自定义帐户

如果必须使用备用标识运行 ASP.NET 工作进程，请确保将所使用的帐户配置为最小特权帐户。这可以限制攻击者设法使用进程安全上下文执行代码所带来的损害。

您可能决定使用备用帐户，因为您需要使用 Windows 身份验证连接到远程 Microsoft SQL Server™ 数据库或网络资源。请注意，可以使用本地 ASPNET 帐户执行上述操作。有关详细信息，请参阅本模块后面的数据访问。

有关 ASP.NET 进程帐户所需的 NTFS 权限的详细信息，请参阅本模块后面的 ACL 和权限。

还应将以下用户权限授予 ASP.NET 进程帐户：

•

从网络访问此计算机

•

作为批作业登录。

•

作为服务登录。

•

拒绝本地登录。

•

拒绝通过终端服务登录。

加密 <processModel> 凭据

如果您需要使用自定义帐户，请不要在 Machine.config 中存储纯文本凭据。应使用 Aspnet_setreg.exe 实用程序在注册表中存储加密的凭据。

•

加密 <processModel> 的凭据

从命令提示符处运行以下命令：

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

此命令会将加密的连接字符串存储在指定的注册表项中，并通过受限制的 ACL 来确保注册表项的安全，该 ACL 为 System、Administrators 和 Creator Owner 授予完全控制权限。

重新配置 <processModel> 元素，并添加以下 userName 和 password 属性。

<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> 元素用于启用模拟。可以模拟：

•

原呼叫方（IIS 验证过的标识）

•

固定标识

模拟原呼叫方

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

模拟使用 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> 的凭据

从命令提示符处运行以下命令：

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

此命令会将加密的连接字符串存储在指定的注册表项中，并通过受限制的 ACL 来确保注册表项的安全，该 ACL 为 System、Administrators 和 Creator Owner 授予完全控制的权限。

重新配置 <identity> 元素，并添加以下 userName 和 password 属性。

<identity impersonate="true"

userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"

password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>

使用 Regedt32.exe 在上述注册表项上创建 ACL，为 ASP.NET 进程帐户授予读取权限。

有关详细信息，请参阅 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> 元素配置应用程序使用的验证模式。

适当的身份验证模式取决于应用程序或 Web Services 是如何设计的。默认的 Machine.config 设置应用安全的 Windows 身份验证默认值，如下所示：

<!-- 验证属性：

mode="[Windows|Forms|Passport|None]" -->

表单身份验证指南

要使用表单身份验证，请在 <authentication> 元素上设置 mode="Forms" 。接下来，使用 <forms> 子元素配置表单身份验证。以下代码片断显示了安全的 <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>

</system.web>

<!-受限制文件夹只能用于验证和 SSL 访问。 -->

<system.web>

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

FileAuthorizationModule HTTP 模块实现。

•

URL 授权。此网关守卫由 ASP.NET

UrlAuthorizationModule HTTP 模块实现。

文件授权

只有使用 Windows 身份验证并具有以下配置的应用程序才可以使用此网关守卫：

使用 Windows 身份验证时，此网关守卫会自动有效，而无需进行模拟。要配置网关守卫，请在文件和文件夹上配置 Windows ACL。请注意，网关守卫只控制对由 IIS 映射到以下 ASP.NET ISAPI 扩展的文件类型的访问：Aspnet_isapi.dll。

URL 授权

任何应用程序都可使用此网关守卫。它是使用 <authorization> 元素进行配置的，这些元素可以控制哪些用户和用户组有权访问应用程序。Machine.config 中的默认元素如下所示：

<!-- 允许/拒绝属性：

users="[*|?|name]"

* - All users

? - Anonymous users

[name] - Named user

roles="[name]" -->

</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)：

</authorization>

</location>

返回页首

会话状态

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

•

在 ASP.NET 工作进程中

•