运行时的 Web 应用程序安全性

更新:2007 年 11 月

在开发应用程序时,必须处理一组安全性问题。另外一组安全性问题(在讨论 Web 安全性时通常是较为突出的问题)则与应用程序在部署和运行时的安全性有关。

按照其定义,Web 应用程序允许用户访问中心资源(即 Web 服务器)并通过此中心资源访问其他资源(如数据库服务器)。当了解并实现正确的安全性措施后,您将:

  • 保护自己的资源不受到未经授权的访问。

  • 按用户或角色限制访问级别。

  • 确保数据完整性和保密性,以提供一个用户能够在其中放心使用应用程序的相对安全的环境。

  • 建立对应用程序访问受限制资源的方式的控制。

  • 确保应用程序的代码按预定方式运行。

本主题将就如何实现这些目标进行一般性讨论,其中还包括指向附加主题的链接,通过这些链接您可以更为详细地了解相关的技术。

利用以下类型的安全性功能,您可以保护应用程序不受到未经授权的访问:

  • 作为常规 Web 服务器功能的一部分由 Internet 信息服务 (IIS) 提供的安全性功能。其中包括 Windows 文件、计算机和用户级别的安全性。

  • 可置入 ASP.NET 应用程序以提供应用程序特定访问的安全性。

ASP.NET 中的安全性进程

IIS 为网站提供多个安全性选项。但是,IIS 安全性机制缺乏针对性,因为所有应用程序都使用相同的机制。此外,IIS 安全性选项(如使用 Windows 集成安全性)有时对于您的应用程序可能并不方便。(另一方面,对于 Intranet 应用程序,您可能为简便起见而需要使用 Windows 集成安全性。)

因此,为了提供对应用程序特定部分的访问,可以使用 ASP.NET 安全性。ASP.NET 安全性与 IIS 安全性一起发挥作用,并对后者进行了扩展,这样,您就可以自定义用户凭据获取方式等功能。

IIS 首先从客户端接收请求,并执行已使用 IIS 管理工具为应用程序建立的任何安全性检查。例如,如果应用程序已经在 IIS 中配置为允许匿名访问,IIS 将不执行任何凭据检查。当执行这一初步的身份验证检查后,IIS 会将该请求发送到 ASP.NET,ASP.NET 可以执行进一步的检查。ASP.NET 允许您使用多种条件在应用程序中指定访问限制:可以将访问限制到特定页或特定用户等。

身份验证

下表说明了 ASP.NET 支持的身份验证方法。其中几种方法与 IIS 身份验证是重叠的。有关详细信息,请参见 ASP.NET 身份验证

身份验证类型

说明

匿名访问

用于未知用户将在其中发出请求的应用程序(通常是公共 Web 应用程序)。与 IIS 重叠。

基本和简要身份验证

(IIS 安全性选项)在此方案中,将提示无凭据的用户提供用户名和密码。

Windows 集成安全性(又称为 NTLM 安全性)

(IIS 安全性选项)如果发出请求的用户已经在基于 Windows 的网络中进行了身份验证,则在请求对资源的访问时,IIS 就可以通过该用户的凭据。

证书身份验证

(IIS 安全性选项)在此方案中,客户端具有已从第三方来源获取的证书(即数字标识)。映射到客户端证书的标识将被传递到 ASP.NET。

Kerberos

(IIS 安全性选项)Kerberos 身份验证协议定义客户端与称作密钥分发中心(Key Distribution Center,KDC)的网络身份验证服务之间的交互。Windows 2000 和 2003 在每个域控制器上以身份验证服务的形式来实现一个 KDC。

Windows 身份验证

(ASP.NET 安全性选项)与以前列出的 IIS 安全性选项集成。ASP.NET 采用 IIS 创建的安全性标记,并使其可以作为 WindowsPrincipal 对象使用,该对象被设置为当前 HttpContextUser 属性的值。

Forms 身份验证

(ASP.NET 安全性选项)如果需要对某用户进行身份验证,ASP.NET 会将请求重定向到您指定的页。该页通常包含一个您要在其中获取用户名信息的窗体。(如需额外的安全性,可以使用 HTTPS 协议交换该窗体。)当应用程序获取窗体信息时,它可以对用户的凭据执行应用程序特定的检查。值得注意的是,身份验证进程在您的控制之下(与 IIS 不同),这使您能够指定窗体的外观并选择存储用户信息的方式。

如果某用户成功通过身份验证,ASP.NET 将颁发一个包含特定标记的加密 Cookie,该标记将为后继的访问标识该用户。

Forms 身份验证对于公共 Internet 上的 ASP.NET 应用程序是最容易的选择,因为这种身份验证使您可以实际控制如何对用户进行身份验证,还可以将身份验证存储在浏览器的标记中。

有关 IIS 安全性的详细信息,请参见 Microsoft TechNet 网站上 Windows Server TechCenter for IIS 中的访问控制主题。有关 ASP.NET 身份验证的详细信息,请参见 ASP.NET 身份验证

有关将 Forms 身份验证与 Windows Server 2003 域环境中的协议转换和约束代理结合使用的详细信息,请参见 Kerberos Protocol Transition and Constrained Delegation(Kerberos 协议转换和约束代理)。

授权

在 Web 应用程序运行时,它需要来自 Web 服务器的资源,而且还经常需要来自其他进程(如数据库)的资源。ASP.NET 进程运行在用户上下文中,此上下文确定了应用程序请求那些资源的方式。在 Windows 2000 和 Windows XP 专业版上,ASP.NET 进程作为一个叫做 ASPNET(默认情况下)的特殊本地用户运行;而在 Windows 2003 上,该进程以 ASP.NET 应用程序池的身份(默认情况下为本地 NETWORK SERVICE 帐户)运行。这些帐户以有限权限运行。您可以为 ASP.NET 进程指定另一个用户上下文,包括本地 SYSTEM 帐户(它在管理员上下文中运行应用程序)或显式提供其凭据的用户,但不推荐这样做。

在 ASP.NET 应用程序中,可以指定不同的用户具有对不同资源的授权访问。如果应用程序使用的是 Windows 身份验证,则可以使用 Windows 权限来确定访问服务器上特定文件或文件夹的授权。

此外,您还可以选择使用基于 URL 的授权,即根据如下的不同条件来给予或拒绝授权:

  • 特定用户或标识,它们基于用户提供的凭据。

  • 角色,即定义来允许多个用户基于共同的角色或功能共享特权的实体。

  • 谓词,即用于访问应用程序各部分的 HTTP 进程(如 GET 和 POST)。

例如,您可以指定所有用户都可以从应用程序中获取页(执行 GET 谓词),但只有特定用户才能向该应用程序发送页。同样,您可能会指定允许所有用户使用 GET 命令来获取页,但拒绝向特定角色授予发送权限。

您可以为整个应用程序提供 URL 授权,也可以逐个目录地提供 URL 授权。一种常见的用途是允许所有用户在一个公共目录中查看页,但将受限制的页保存在另一个目录中,该目录仅对特定的用户或角色授权。

yfe5dwc2.alert_note(zh-cn,VS.90).gif说明:

默认情况下,通过 IIS 提供的静态文件(如图像和样式表)无需经过 ASP.NET 授权。如果不希望所有用户都能够访问静态文件,可以使用 IIS 安全性功能限制对这些文件的访问。如果使用 ASP.NET Development Server 测试 ASP.NET 应用程序,将看到不同的行为,这是因为当禁止匿名访问静态文件时,这些文件要经过 ASP.NET 授权,并且不会提供给匿名用户。此外,可以将 IIS 中的静态文件扩展名映射到 ASP.NET ISAPI 扩展名,在这种情况下,将应用 ASP.NET 授权规则。

有关更多信息,请参见 ASP.NET 授权Web 应用程序的基本安全实施策略

ASP.NET 配置文件

ASP.NET 安全性选项是使用 Web.config 文件中的设置建立的。该文件允许您包括多种安全性选项的预定义元素(包括身份验证节和授权节)。Web.config 文件的相关节可能类似于下面这样。

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" />
    </authentication>
    <authorization>
      <deny user="?" />
    </authorization>
  </system.web>
</configuration>

您的应用程序可以包含多个配置文件。默认情况下,应用程序根处有一个配置文件,它指定整个应用程序的安全性,即由子文件夹继承的安全性设置。但是,也可以在单独的文件夹中创建配置文件,以创建该文件夹的安全性设置。

有关更多信息,请参见 ASP.NET 结构

XML Web services 安全性

使用 .asmx 文件的 XML Web services 是作为使用 ASP.NET 的 Web 应用程序来运行的,因此它们所参与的安全性模型与任何 ASP.NET 应用程序所参与的安全性模型都相同。例如,XML Web services 可能配置为使用基本身份验证或 Windows 集成安全性。

在设计时,当您尝试向 XML Web services 添加引用(即请求 XML Web services 的发现文档)时,XML Web services 将按照它的配置来执行标准的 Web 应用程序身份验证。例如,如果 XML Web services 配置为使用基本身份验证,该服务将需要从发出请求的客户端获取用户名和密码。例如,如果 XML Web services 使用的是基本身份验证,“添加 Web 引用”对话框将提示您提供凭据。

如果您正在生成的应用程序包含对 XML Web services 的调用,则需要确保在进行调用之前具有正确的凭据,否则该调用将会失败。在运行时,可以通过在调用 XML Web services 的方法之前设置表示 XML Web services 的客户端对象的 Credentials 属性来向 XML Web services 传递凭据。

由于其他 ASP.NET 安全性选项可能不够灵活,XML Web services 可以实现一种凭据信息在 SOAP 标头中进行传递的自定义身份验证解决方案。在该解决方案中,凭据在客户端和服务器之间交换的消息的可选部分进行传递。然后,您可以编写一个自定义的 HTTP 模块(实现 IHttpModule 接口),它可以侦听标头中的信息并调用您的身份验证代码。

与其他 ASP.NET 应用程序相同,XML Web services 可能会实现基于特定角色的授权,以限制对应用程序特定部分的访问。

有关详细信息,请参见 XML Web services 基础结构保证使用 ASP.NET 创建的 XML Web services 的安全

确保数据完整性和保密性

身份验证和授权确定您的用户是谁以及他们可以访问哪些资源。这些安全性功能主要用于保护您的 Web 应用程序不受到未经授权的使用。

但是,安全性还有一个不同的方面,即保护用户的信息,使用户能够放心地与您交换敏感信息。例如,如果您的应用程序要求用户提供信用卡号或其他帐户编号、个人信息或任何用户可能不希望其他人知道的数据,则必须提供一种使他们能够安全地向您提交这些信息的方式。

可以使用 IIS 中的安全套接字层 (SSL) 来交换通过 HTTPS 协议加密的信息。SSL 提供了双向的加密:您的信息经过加密传输给用户,而用户向您的应用程序发送的信息同样也得到加密。

建立 SSL 和加密

若要使用 SSL 和加密,必须获取您所在公司或标识的服务器证书。证书是一种数字签名,它标识您的站点,使其无法被模拟。对于 Internet(公共)应用程序,可以从公认的第三方证书颁发机构获取服务器证书。对于私有 (Intranet) 应用程序,您自己就可以颁发服务器证书。您这样做的目的可能是为了确保内部应用程序(如个人站点)的安全。

使用服务器证书,还可以与浏览器用户建立 SSL 加密的连接。SSL 使用的是名为公钥加密的加密方法。这种形式的加密机制中有两个密钥:公钥用于对数据进行加密;私钥由您密存,用于对用公钥加密的信息进行解密。您所获取的服务器证书包含一个公钥。当用户需要使用 SSL 时,您的应用程序将向浏览器发送证书和公钥。然后,浏览器和服务器使用公钥来建立一种对它们的信息交换进行加密的方式。

yfe5dwc2.alert_note(zh-cn,VS.90).gif说明:

使用 SSL 时要求浏览器支持的加密密钥至少为 40 位长。大多数浏览器都可以提供这种加密级别。但是,这种密钥长度不被视为是安全的。您可以选择在 IIS 中将自己的应用程序配置为仅允许使用 128 位密钥的 SSL 连接。

当获取服务器证书后,可以指示用户将 https:// 用作前缀来获取和发送网页,以使用 SSL。您还可以在 IIS 中将自己的网站配置为仅接受 HTTPS 连接。IIS 和浏览器将自动使用加密信道来交换信息。

有关如何使用 SSL 的详细信息,请参见 Microsoft 知识库中的文章 Q307267“How to: Secure XML Web Services with Secure Sockets Layer in Windows 2000”(如何:在 Windows 2000 中使用安全套接字层保护 XML Web services)。有关加密的信息,请参见加密概述。有关证书和配置 SSL 的信息,请参见 Microsoft TechNet 网站上的 Windows Server TechCenter for IIS

使用 .NET 代码安全性

安全性的最后一个方面是应采取措施确保应用程序中的代码受到保护,不会被不正当地使用(例如,因为疏忽而在不正确的上下文中运行,或者被以恶意的方式使用)。由于 ASP.NET 是 .NET Framework 的一部分,因此,您也可以利用代码访问安全性来建立权限,即允许代码执行哪些操作。有关信息,请参见代码访问安全性

请参见

概念

Web 应用程序的基本安全实施策略