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

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

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

加密 <processModel> 凭据。

不将 ASP.NET 作为 SYSTEM 运行。

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

加密 <processModel> 的凭据

1.

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

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

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

2.

重新配置 <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>

<identity> 元素用于启用模拟。可以模拟：

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

固定标识

模拟原呼叫方

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

<identity impersonate="true" />

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

1.

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

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

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

2.

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

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

3.

使用 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> 元素配置应用程序使用的验证模式。

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

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

对网站进行分区。

设置 protection="All"。

使用小 Cookie 超时值。

考虑使用固定的有效期.

对表单身份验证使用 SSL.

如果不使用 SSL，请设置 set slidingExpiration = "false"。

不要在生产服务器上使用 <credentials> 元素。

配置 <machineKey> 元素。

使用唯一的 Cookie 名称和路径。

对网站进行分区

可以将网站的公共访问区和受限制访问区分开。将只允许通过身份验证的用户访问的应用程序登录页和其他页面以及资源放在一个单独的文件夹中，与公共访问区分开。通过在 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 是窃取登录。

设置 requireSS

上一页  [1] [2] [3] [4] [5] [6] [7]  下一页

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

鄂公网安备 42011102001154号

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