构建安全的ASPNET应用程序.docx

资源描述

构建安全的ASPNET应用程序.docx

《构建安全的ASPNET应用程序.docx》由会员分享，可在线阅读，更多相关《构建安全的ASPNET应用程序.docx（47页珍藏版）》请在冰点文库上搜索。

构建安全的ASPNET应用程序.docx

构建安全的ASPNET应用程序

构建安全的ASP.NET应用程序

身份验证、授权和安全通信

第5章—Intranet安全性

J.D.Meier、AlexMackman、MichaelDunner和SrinathVasireddy

MicrosoftCorporation

2002年10月

有关构建安全的ASP.NET应用程序的起点和完整概述，请参见登陆页面。

总结

本章介绍如何保护常见的Intranet应用程序方案的安全。

还介绍每种方案的特点以及保护各方案的安全所需的步骤。

还包括分析部分以提供进一步的信息。

内容

ASP.NET到SQLServer

ASP.NET到EnterpriseServices到SQLServer

ASP.NET到Web服务到SQLServer

ASP.NET到Remoting到SQLServer

点对点安全性

将原调用方传递到数据库

总结

对Intranet应用程序的访问被限制到一组有限的授权用户（例如，属于某个域的雇员）。

虽然Intranet设置限制了应用程序的公开，但是当您制定身份验证、授权和安全通信策略时，可能仍要面临一些难题。

例如，您可能包含非信任域，因此很难将调用方的安全性上下文和标识传递到系统内的后端资源。

另外，您的运行环境可能是具有混合浏览器类型的异类环境。

因此，更加不便使用通用身份验证机制。

如果同类Intranet中的所有计算机均运行Microsoft®Windows®2000或更高版本的操作系统，并且在域中信任用户使用委派，则可以选择将原调用方的安全性上下文委派到后端。

您还必须考虑安全通信问题。

尽管您的应用程序运行在Intranet环境中，也不能认为在网络中传送的数据是安全的。

除了需要保护应用程序服务器和数据库之间传送的数据外，可能还需要保护浏览器和Web服务器之间传送的数据。

本章使用以下常见的Intranet方案来阐释主要的身份验证、授权和安全通信技术：

●ASP.NET到SQLServer

●ASP.NET到EnterpriseServices到SQLServer

●ASP.NET到Web服务到SQLServer

●ASP.NET到Remoting到SQLServer

此外，本章还介绍了一个Windows2000委派方案（“将原调用方传递到数据库”）。

在此方案中，使用中间Web服务器和应用程序服务器，在操作系统级别将原调用方的安全性上下文和标识从浏览器传递到数据库。

注意：

本章中描述的几个方案或者替换用于运行ASP.NET应用程序的默认ASPNET帐户，或者更改其密码以允许在远程计算机上创建重复的帐户。

这些方案更新Machine.config中的元素。

这样，就可以将凭据以明文形式存储在machine.config中。

有关该主题的详细讨论，请参见第8章“ASP.NET安全性”中的“访问网络资源”。

ASP.NET到SQLServer

在此方案中，人力资源数据库在同类Intranet中安全地提供每个用户的数据。

应用程序使用受信任的子系统模型并代表原调用方执行调用。

应用程序使用集成Windows身份验证来验证调用方的身份，并使用ASP.NET进程标识来调用数据库。

由于数据本身所具有的机密性，因此，在Web服务器和客户端之间使用了SSL。

图5.1显示此应用程序方案的基本模型。

{Insertfigure:

CH05-Intranet–ASPNETtoSQLServer.gif}

图5.1

ASP.NET到SQLServer

特点

本方案具有以下特点：

●客户端上安装了InternetExplorer。

●用户帐户位于MicrosoftActiveDirectory®目录服务中。

●应用程序提供每个用户的机密数据。

●只有经过身份验证的客户端能够访问应用程序。

●数据库委派该应用程序对用户进行正确的身份验证（即，应用程序代表用户对数据库进行调用）。

●MicrosoftSQLServer™使用单个数据库用户角色进行授权。

保护方案

在此方案中，Web服务器验证调用方的身份，并通过使用调用方的标识限制对本地资源的访问。

要限制原调用方对资源的访问，您不必在Web应用程序中进行模拟。

数据库验证ASP.NET默认进程标识（它是权限最少的帐户）的身份（即数据库信任ASP.NET应用程序）。

表5.1：

安全措施

类别

详细信息

身份验证

●通过在IIS中使用集成Windows身份验证，在Web服务器上提供增强身份验证来验证原调用方的身份。

●在ASP.NET内使用Windows身份验证（不模拟）。

●通过将SQLServer配置为使用Windows身份验证，确保数据库连接的安全。

●数据库信任ASP.NET辅助进程以进行调用。

可以在数据库中验证ASP.NET进程标识的身份。

授权

●使用绑定到原调用方的ACL在Web服务器上配置资源。

为了简化管理，将用户添加到Windows组中并在ACL中使用组。

●Web应用程序对原调用方执行.NET角色检查，以限制对页面的访问。

安全通信

●保护在Web服务器和数据库之间传送的机密数据

●保护在原调用方和Web应用程序之间传送的机密数据

结果

图5.2显示了此方案的建议安全配置。

{Insertfigure:

CH05-Intranet-ASP.NETtoSQLServer（Solution）.gif}

图5.2

ASP.NET到SQLServerIntranet方案的建议安全配置

安全配置步骤

在开始之前，您需要查看以下内容：

●创建自定义ASP.NET帐户（请参见本指南“参考”部分的“如何做：

创建自定义帐户以便运行ASP.NET”）

●创建一个权限最少的数据库帐户（参见第12章“数据访问安全性”）

●在Web服务器上配置SSL（请参见本指南“参考”部分的“如何做：

在Web服务器上设置SSL”）

●配置IPSec（请参见本指南“参考”部分的“如何做：

使用IPSec以便在两台服务器之间安全通信”）

配置IIS

步骤

更多信息

禁用对Web应用程序的虚拟根目录的匿名访问

启用集成的Windows身份验证

要使用IIS身份验证设置，请使用IISMMC管理单元。

右击应用程序的虚拟目录，然后单击“属性”。

单击“目录安全性”选项卡，然后单击“匿名访问和验证控件”组中的“编辑”。

配置ASP.NET

步骤

更多信息

将ASPNET密码更改为一个已知的强密码值

ASPNET是权限最少的本地帐户，默认情况下用来运行ASP.NETWeb应用程序。

通过使用“本地用户和组”将ASPNET帐户的密码设置为一个已知值。

编辑位于%windir%\Microsoft.NET\Framework\v1.0.3705\CONFIG中的Machine.config

并重新配置元素的密码属性

默认

--userName="machine"password="AutoGenerate"-->

成为

--userName="machine"password="YourNewStrongPassword"-->

将ASP.NETWeb应用程序配置为使用Windows身份验证

编辑应用程序的虚拟根目录下的Web.config

将元素设置为：

确保模拟处于关闭状态

默认情况下模拟处于关闭状态；不过，请执行如下操作，再次检查以确保它在Web.config中是关闭的：

删除元素也能达到同样的效果。

配置SQLServer

步骤

更多信息

在SQLServer计算机上创建一个与ASP.NET进程帐户（ASPNET）匹配的Windows帐户

用户名和密码必须与ASPNET帐户匹配。

给予该帐户以下权限：

-从网络访问此计算机

-拒绝本地登录

-以批处理作业登录

配置SQLServer以便进行Windows身份验证

为本地ASPNET帐户创建一个SQLServer登录

这将授予对SQLServer的访问权限

创建一个新数据库用户，并将登录名映射到数据库用户

这将授予对指定数据库的访问权限

创建一个新的用户定义的数据库角色，并将数据库用户添加到该角色

建立该数据库角色的数据库权限

授予最少的权限

有关详细信息，请参见第12章“数据访问安全性”。

配置安全通信

步骤

更多信息

配置Web站点的SSL

请参见本指南“参考”部分的“如何做：

在Web服务器上设置SSL”。

配置Web服务器和数据库服务器之间的IPSec

请参见本指南“参考”部分的“如何做：

使用IPSec以便在两个服务器之间安全通信”。

分析

●在此方案中，由于所有用户都使用Windows帐户并且使用的是MicrosoftInternetExplorer，所以在IIS中最好使用集成Windows身份验证。

集成Windows身份验证的优点是从不通过网络传送用户的密码。

此外，由于Windows使用当前交互式用户的登录会话，所以对于用户来说登录是透明的。

●ASP.NET作为权限最少的帐户运行，所以，一旦遭到攻击，潜在危害被大大降低。

●要执行.NET角色检查或在WindowsACL中针对原调用方保证资源的安全，您不必在ASP.NET中进行模拟。

为了对原调用方执行.NET角色检查，按如下所示从HTTP上下文中检索代表原调用方的WindowsPrincipal对象：

WindowsPrincipalwp=（HttpContext.Current.UserasWindowsPrincipal）;

if（wp.IsInRole（"Manager"））

{

//Userisauthorizedtoperformmanager-specificfunctionality

}

ASP.NETFileAuthorizationModule针对原调用方在ACL中检查在IIS中映射到aspnet_isapi.dll的ASP.NET文件类型。

对于静态文件类型（例如.jpg、.gif和.htm文件），IIS充当关守，它根据文件的相关NTFS权限，使用原调用方的标识执行访问检查。

●对SQLServer使用Windows身份验证意味着，不必将凭据存储在文件中并通过网络将凭据传递到数据库服务器。

●在数据库服务器上使用重复的Windows帐户（与ASP.NET本地帐户匹配的帐户）会导致增加管理负担。

如果一台计算机上的密码有改动，则必须在其他计算机上同步并更新它。

在某些方案中，您可能能够使用权限最少的域帐户进行更简单的管理。

●当设置防火墙时（此时Windows身份验证所需的端口可能没有打开），重复的本地帐户方法同样有效。

在此方案中可能无法使用Windows身份验证和域帐户。

●您需要确保Windows组的粒度与您的安全要求一样。

由于基于.NET角色的安全性以Windows组成员身份为基础，所以此解决方案依赖于以正确的粒度设置Windows组，以便与访问应用程序的用户类别（共享相同的安全权限）匹配。

这里用来管理角色的Windows组可以是此计算机的本地组或域组。

●SQLServer数据库用户角色优先于SQLServer应用程序角色，这样可以避免与使用SQL应用程序角色有关的密码管理和连接池问题。

应用程序通过用角色名和密码调用内置的存储过程，来激活SQL应用程序角色。

因此，必须安全地存储密码。

当使用SQL应用程序角色时，还必须禁用数据库连接池，因为它会严重影响应用程序的可伸缩性。

有关SQLServer数据库用户角色和SQLServer应用程序角色的详细信息，请参见第12章“数据访问安全性”。

●将数据库用户添加到数据库用户角色中，并且为角色指定了权限，因此，当数据库帐户更改时，您不必更改所有数据库对象的权限。

问与答

●为什么我不能启用Web应用程序模拟，以便使用配置的ACL针对原调用方来保护Web应用程序所访问的资源？

如果启用模拟，则模拟的安全性上下文不具有网络凭据（假定未启用委派并且您使用的是集成Windows身份验证）。

因此，对SQLServer的远程调用将使用NULL会话，而这将会导致调用失败。

如果禁用模拟，则远程请求使用ASP.NET进程标识。

上述方案使用ASP.NETFileAuthorizationModule，它使用WindowsACL针对原调用方标识执行授权，并且不要求进行模拟。

如果您使用基本身份验证而不是集成Windows身份验证（NTLM），并且确实启用了模拟，则每个数据库调用都将使用原调用方的安全性上下文。

每个用户帐户（或用户所属的Windows组）都要求使用SQLServer登录。

需要限制Windows组（或原调用方）访问数据库对象的权限以确保安全性。

●数据库不知道谁是原始调用方。

我如何能创建一条审核记录？

审核Web应用程序中的最终用户活动，或者将用户标识作为数据访问调用的参数明确地进行传递。