确保 ASP.NET 应用程序和 Web Services 的安全
确保 ASP.NET 应用程序和 Web Services 的安全
更新日期: 2004年04月12日本页内容
本模块内容
安全的 ASP.NET Web 应用程序依赖于完全安全的网络、主机和平台基础结构。当上述条件满足后,攻击者将尝试利用 Web 应用程序和 Web Services(通常在端口 80 上侦听)中的漏洞。如果未有效配置 Web 应用程序,攻击者可能会获得系统的访问权限并利用系统。
作为管理员,您必须检查默认的计算机级配置和各个应用程序配置,以处理和删除所有漏洞或不安全设置。
本模块从系统管理员的角度描述了 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 允许在注册表中以加密格式存储凭据和连接字符串。此工具允许加密下列属性:
•<processModel userName = password= />
•<identity username = password= />
•<sessionState sqlConnectionString = stateConnectionString= />
以下示例显示了运行 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:配置文件的位置
配置文件 位置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>
<location> 元素主要用于三个目的:
•将配置设置应用于特定的应用程序文件。
•通过在 Machine.config 中应用应用程序特定的设置进行集中管理。
•锁定配置设置以阻止应用程序级覆盖。
可以在 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 文件变得更小。
需要考虑的主要问题是计算机策略应该强制使用哪些设置。这取决于特定的方案。一些通用方案如下所示:
•Windows 身份验证考虑一个企业的 Intranet 门户方案,在这个方案中,您希望将验证与应用程序分离,并由组织通过 Active Directory 控制验证。在此方案中,可以强制使用 Windows 身份验证,但允许单个应用程
【相关文章:】
让ASP.NET更好用--DreamwaverMX与ASP.NET(一)
在ASP与ASP.NET之间共享对话状态(2)
在ASP与ASP.NET之间共享对话状态(1)
asp.net中操作文件
asp.net发送邮件详解
在ASP.NET中如何用C#.NET实现基于表单的验证
ASP.NET WEB页面多语言支持解决方案
asp.net窗体的打开和关闭
在 ASP.NET 中执行 URL 重写
ASP.NET 2.0 Beta2 中特殊文件夹名称的改变
【发表评论】【打印此文】【关闭窗口】【点击数: 】
