通过

规划步骤 4：规划应用程序安全性

  • 项目

作者：Keith Newman 和 Robert McMurray

在此生成网站的阶段中，考虑你的 ASP.NET 应用程序的安全性需求。 以下各节介绍了 IIS 8 中可用的应用程序安全性设置：

4.1. 隔离 Web 应用程序

提高 web 应用程序的安全性的最有效方法之一是将其从 web 服务器上的其他应用程序隔离。 应用程序池都有其自己的工作进程，后者处理请求并运行应用程序代码。 工作进程具有安全标识符 (SID)。 所有 Web 应用程序池都使用相同应用程序池标识。 默认情况下，在创建 Web 应用程序时，使用与应用程序相同的名称来创建一个新应用程序池。 如果你将 Web 应用程序保留在单独的应用程序池，你可以从另一个应用程序中隔离它们。

Web 应用程序隔离必需的下列操作：

  • 站点隔离：使用不同的应用程序池将不同的应用程序分离到不同的站点。
  • 最低特权：以每个站点唯一的低特权标识（虚拟应用程序池标识）运行你的工作进程。
  • 临时隔离：为每个站点设置单独的 ASP.NET 临时文件夹，并仅授予对相应进程标识的访问权限。
  • 内容隔离：请确保在每个站点根路径上设置 ACL（访问控制列表）以仅允许访问相应的进程标识。

提示

它是一个好办法承载您的系统驱动器 (c:) 以外的驱动器上的网站和 web 应用程序内容。

4.2。 .NET 信任级别

应用程序信任级别可确定 ASP.NET 代码访问安全性 (CAS) 策略授予的权限。 CAS 定义了两种信任类别：完全信任和部分信任。 具有完全信任权限的应用程序可以访问服务器上所有类型的资源并执行特权操作。 完全信任的应用程序只受操作系统的安全性设置的影响。

部分信任的 Web 应用程序是不具有完全信任但具有一组受限的代码访问权限的应用程序。 因此，部分信任的应用程序在访问安全资源和执行其他特权操作上的能力受限。 由于拒绝向部分信任的应用程序提供某些权限，因此它们无法直接访问需要这些权限的资源。 其他权限通过受限方式进行授予，因此它们可能可以访问需要这些权限的资源，但访问是受限的。 例如，向应用程序提供的受限文件 IO 权限可以访问文件系统，但仅限位于应用程序的虚拟根目录下面的目录。

通过将 Web 应用程序或 Web 服务配置为部分信任，你可以限制应用程序访问关键系统资源或属于其他 Web 应用程序的资源的能力。 通过仅授予应用程序所需的权限，你可以生成最少特权的 Web 应用程序并限制 Web 应用程序遭到代码注入攻击时的潜在损坏程度。

以下列表显示了与每个信任级别相关联的限制：

  • 完全信任的应用程序可以无限制地访问所有资源类型，并且可以执行特权操作。
  • 高级、中级、低级或最小级别的信任应用程序无法调用非托管代码或服务组件、写入事件日志、访问“消息队列”队列或访问 OLE DB 数据源。
  • 高级信任应用程序可以无限制地访问文件系统。
  • 中级信任应用程序具有受限的文件系统访问权限，并且仅可访问位于其自身的应用程序目录层次结构中的文件。
  • 低级或最小级别的信任应用程序无法访问 SQL Server 数据库。
  • 最小级别的信任应用程序无法访问任何资源。

4.3。 .NET 身份验证

身份验证有助于确认请求访问你的站点和应用程序的客户端的标识。 启用身份验证后，IIS 8 将使用用户提供的帐户凭据来确定向用户授予的权限以及用户可访问的资源。

本部分介绍了特定于 ASP.NET 应用程序的身份验证模式。

  1. ASP.NET 表单身份验证
  2. ASP.NET 模拟身份验证

ASP.NET 表单身份验证

表单身份验证使用客户端重定向将未经过身份验证的用户重定向至一个 HTML 表单，用户可以在该表单中输入凭据，通常是用户名和密码。 确认凭据有效后，系统会将用户重定向至他们最初请求的页面。 表单身份验证通常采用 Cookie 在服务器和客户端浏览器之间传递用户凭据。

以下部分介绍了计划将表单身份验证添加到你的站点时需要了解的内容：

  1. 表单身份验证基础知识
  2. 身份验证 Cookie

表单身份验证基础知识

基于 ASP.NET 表单的身份验证非常适用于公共 Web 服务器上接收大量请求的站点或应用程序。 此身份验证模式使你能够在应用程序级别管理客户端注册和身份验证，而无需依赖操作系统提供的身份验证机制。

重要

因为表单身份验证以纯文本形式向 Web 服务器发送用户名和密码，因此请为应用程序中的登录页面和其他所有页面（主页除外）使用安全套接字层 (SSL) 加密。 有关 SSL 的信息，请参阅 4.5.TLS/SSL 通信。

表单身份验证允许用户使用 ASP.NET 成员资格数据库中的标识进行登录。 此身份验证方法使用指向 HTML 登录页面的重定向来确认用户的身份。 你可以在站点或应用程序级别配置表单身份验证。

表单身份验证非常方便，原因如下：

  • 它允许使用自定义数据存储（例如 SQL Server 数据库）或 Active Directory 进行身份验证。
  • 它可轻松与 Web 用户界面集成。
  • 客户端可以使用任何浏览器。

如果想要使用成员资格角色进行身份验证，请使用表单身份验证或类似的自定义身份验证方法。

重要

如果选择表单身份验证，则无法同时使用任何基于质询的身份验证方法。

默认情况下，表单身份验证的登录 URL 为 Login.aspx。 你可以为访问站点或应用程序的客户端创建唯一登录页面。 例如，你可能需要从访问者处收集特定信息，或者向站点上选定页面或选定应用程序提供成员资格。

表单身份验证的默认超时值为 30 分钟。 请考虑将此超时值更改为更短的时间，以缩短会话生存期和减少 Cookie 重播攻击的机会。

身份验证 Cookie

将身份验证 Cookie 用作验证客户端是否有权访问应用程序的部分或全部页面的令牌。 相比之下，个性化 Cookie 包含特定于用户的设置，这些设置可确定特定站点或应用程序上的用户体验。

重要说明：每次发送请求时客户端与服务器之间都会传递身份验证 Cookie，因此应始终使用安全套接字层 (SSL) 来保护身份验证 Cookie。 有关 SSL 的信息，请参阅 4.5.TLS/SSL 通信。

与查询字符串相比，Cookie 是一种更有效的跟踪站点访问者的方式，因为它们不需要重定向。 但是，它们依赖于浏览器，而有些浏览器并不支持使用 Cookie。 此外，由于某些用户在其浏览器中禁用了 Cookie 支持，因此使用基于 Cookie 的身份验证并非总是有效的。

默认情况下，ASP.NET 应用程序的 Cookie 名称为 .ASPXAUTH。 但是，你可以为每个应用程序改用唯一的 Cookie 名称和路径。 这样做可以防止针对一个应用程序进行了身份验证的用户通过 Web 服务器上其他应用程序的身份验证。

你可以为站点或应用程序选择以下 Cookie 模式之一：

“模式” 说明
使用 Cookie 始终使用 Cookie，而不考虑设备。
不使用 Cookie 不使用 Cookie。
自动检测 如果设备配置文件支持 Cookie，则使用 Cookie。 否则，不使用 Cookie。 对于已知支持 Cookie 的桌面浏览器，ASP.NET 通过检查来确定是否启用了 Cookie。 此设置为默认设置。
使用设备配置文件 如果设备配置文件支持 Cookie，则使用 Cookie。 否则，不使用 Cookie。 ASP.NET 不会通过检查来确定在支持 Cookie 的设备上是否启用了 Cookie。 此设置是 IIS 8 的默认设置。

Cookie 保护模式可定义表单身份验证 Cookie 对特定应用程序所执行的功能。 下表显示了可定义的 Cookie 保护模式：

“模式” 说明
加密和验证 指定应用程序同时使用数据验证和加密来帮助保护 Cookie。 此选项使用配置的数据验证算法（基于计算机密钥）。 如果三重 DES (3DES) 可用并且密钥够长（48 个字节或更长），则使用 3DES 进行加密。 此设置是默认（建议）值。
无 指定对仅将 Cookie 用于个性化且安全要求较低的站点禁用加密和验证。 我们不建议采用此方式使用 Cookie；但是，这是在使用 .NET Framework 启用个性化时最节省资源的一种方式。
加密 指定使用三重 DES 或 DES 对 Cookie 进行加密，但不对 Cookie 执行数据验证。 以这种方式使用的 Cookie 可能易于受到纯文本攻击的影响。
验证 指定验证方案验证已加密的 Cookie 的内容在传输过程中是否未发生更改。

重要

为提高安全性，请考虑将加密 Cookie 和验证 Cookie 隔开。 与验证 Cookie 被盗相比，加密 Cookie 被盗所带来的安全隐患更大。

如果应用程序包含客户端经常请求的对象，则通过缓存这些对象来提高应用程序性能。 如果用户在身份验证 Cookie 超时前访问缓存的对象，则 IIS 8 将允许缓存的对象保留在缓存中，并且会重置计时器。 但是，如果用户在这段时间内没有访问缓存的对象，则 IIS 8 会将缓存的对象从缓存中删除。

在以下情况下，请考虑启用此设置：

  • 可用于进行缓存的内存量有限。
  • 需要缓存的对象很多，因为此设置仅允许将请求最频繁的对象保留在缓存中。

注意

需要使用“身份验证 Cookie 超时(分钟)”指定了等待多少分钟后身份验证 Cookie 即会超时。

ASP.NET 模拟身份验证

如果要在 ASP.NET 应用程序的非默认安全上下文中运行 ASP.NET 应用程序，请使用 ASP.NET 模拟。

如果为某个 ASP.NET 应用程序启用了模拟，该应用程序则可以在以下两种不同上下文的任一上下文中运行：作为通过 IIS 8 身份验证的用户或作为你设置的任意帐户。 例如，如果你使用匿名身份验证，并选择作为已通过身份验证的用户运行 ASP.NET 应用程序，则该应用程序将在为匿名用户设置的帐户（通常为 IUSR）下运行。 同样，如果你选择在任意帐户下运行应用程序，它将在为该帐户设置的任意安全上下文中运行。

默认情况下，ASP.NET 模拟处于禁用状态。 启用模拟后，ASP.NET 应用程序将在通过 IIS 8 身份验证的用户的安全上下文下运行。

4.4。 计算机密钥设置

计算机密钥有助于保护表单身份验证 Cookie 数据和页级视图状态数据。 它们还会验证进程外会话状态标识。 ASP.NET 使用以下类型的计算机密钥：

  • 验证密钥可计算消息验证代码 (MAC) 以确认数据的完整性。 此密钥将附加到表单身份验证 Cookie 或特定页的视图状态。
  • 解密密钥用于对表单身份验证票证和视图状态进行加密和解密。

借助 IIS 8，你可以配置验证和加密设置并生成与 ASP.NET 应用程序服务（例如视图状态、表单身份验证、成员资格、角色和匿名标识）一起使用的计算机密钥。

在为你的应用程序生成计算机密钥之前，请做出以下设计决策：

  • 确定要使用的验证方法：AES、MD5、SHA1（默认）、TripleDES、HMACSHA256、HMACSHA384 或 HMACSHA512。
  • 确定要使用的加密方法：自动（默认）、AES、TripleDES 或 DES。
  • 确定是否在运行时自动生成验证密钥。
  • 确定是否为每个应用程序生成唯一验证密钥。
  • 确定是否在运行时自动生成解密密钥。
  • 确定是否为每个应用程序生成唯一解密密钥。

4.5。 TLS/SSL 通信

传输层安全性 (TLS) 及其前身安全套接字层 (SSL) 均是为你的网站提供通信安全性的协议。 可以使用 TLS/SSL 验证服务器和客户端，然后使用它来加密经过身份验证的双方之间的消息。

在身份验证过程中，TLS/SSL 客户端向 TLS/SSL 服务器发送消息，服务器使用服务器需要验证自身身份的信息进行响应。 客户端和服务器执行会话密钥的额外交换，身份验证对话结束。 身份验证完成后，SSL 保护的通信可使用在身份验证过程中创建的对称加密密钥在服务器和客户端之间开始进行。

若要为你的网站配置 TSL/SSL，请执行以下操作：

  1. 从证书颁发机构 (CA) 获取服务器证书。 请参阅服务器证书。
  2. 将 SSL 绑定添加到站点。 请参阅 SSL 绑定。
  3. 将 IIS 设置为在该站点上需要 SSL。 请参阅要求你的站点使用 SSL。
  4. 请考虑为你的站点使用客户端证书。 请参阅客户端证书。

服务器证书

可以从证书颁发机构 (CA) 获取服务器证书。 从证书颁发机构获取服务器证书是配置安全套接字层 (SSL) 或传输层安全性 (TLS) 的一个步骤。 可以从第三方 CA 获取服务器证书。 第三方 CA 在颁发证书之前可能会要求你提供身份证明。 还可以通过使用联机 CA（例如 Microsoft 证书服务）颁发自己的服务器证书。

数字证书是电子文件，其运行方式如同可验证用户或计算机身份的联机密码。 它们用于创建用于客户端通信的 SSL 加密通道。 证书是由证明证书持有者的身份的证书颁发机构 (CA) 颁发的数字声明，它使各方可通过使用加密来采用安全方式进行通信。

数字证书执行以下操作：

  • 确认其持有者（用户、网站，甚至是路由器等网络资源）自称的身份的确属实。
  • 保护联机交换的数据免遭被盗或篡改。

数字证书由受信任的第三方 CA 或使用证书服务的 Microsoft Windows 公钥基础结构 (PKI) 颁发，或者它们可能是自签名证书。 每种类型的证书都有优点和缺点。 每种类型的数字证书都是防篡改的，无法伪造。

可针对多种用途颁发证书。 这些用途包括 Web 用户身份验证、Web 服务器身份验证、安全/多用途 Internet 邮件扩展 (S/MIME)、Internet 协议安全性 (IPsec)、传输层安全性 (TLS) 和代码签名。

证书包含一个公钥，并将该公钥附加至用户、计算机或持有相应私钥的服务的身份。 公钥和私钥由客户端和服务器用于在数据传输前对数据进行加密。 对于基于 Windows 的用户、计算机和服务，当受信任的根证书存储中存在根证书的副本且该证书包含有效的证书路径时，将在 CA 中建立信任。 若要证书有效，不得吊销证书，并且有效期不得过期。

SSL 绑定

如果有些站点内容具有不同的用途或必须使用不同的协议，则可以为站点分配多个绑定。 例如，在商业站点上，可能会有一个应用程序要求用户先登录帐户，然后才能购买商品。 该公司通过 HTTP 托管该站点，但用户必须在 HTTPS 页面上登录他们的帐户。 在此示例中，该站点会有两个绑定：一个用于 HTTP 部分，另一个用于 HTTPS 部分。

默认情况下，不能使用 IIS 管理器为 HTTP 和 HTTPS 之外的协议添加绑定。 如果要为其他协议（例如受 Windows Communication Foundation (WCF) 支持的协议）添加绑定，请使用其他管理工具。 但是，如果安装 IIS 文件传输协议 (FTP) 服务器，则可使用 IIS 管理器添加 FTP 绑定。 此外，可能还有其他扩展该 UI 的模块或第三方功能可供下载。

要求你的站点使用 SSL

安全套接字层 (SSL) 加密可对客户端与服务器之间发送的机密信息或个人信息提供保护。 启用 SSL 时，远程客户端将使用以 https:// 开头的 URL 访问你的站点。

首先配置服务器证书并创建 HTTPS 绑定来启用任何 SSL 设置。 然后在以下一种或多种情况下，要求使用安全套接字层 (SSL) 加密：

  1. 当服务器上的机密内容或个人内容必须使用加密通道进行保护时。
  2. 当你希望用户在传输其个人信息之前能够确认服务器的标识时。
  3. 当你希望使用客户端证书对访问服务器的客户端进行身份验证时。

客户端证书

如果你希望客户端在访问 Web 服务器上的内容之前验证其标识，请配置客户端证书。 默认情况下，将忽略客户端证书。

首先需要配置服务器证书并创建 HTTPS 绑定以启用任何安全套接字层 (SSL) 设置，然后才能在你的网站上配置客户端证书。

如果你希望所有客户端都验证自己的标识，请指定需要使用客户端证书。 如果要使某些客户端可访问内容且无需事先验证其标识，请指定接受客户端证书。