2.2.3 使用Windows验证

小结：Windows验证可以是安全的，但只有在经过适当配置的情况下才是如此。

威胁：账户劫持、中间人、信息泄漏

除了表单验证之外，ASP.NET还提供了对本地IIS验证方法的支持，这些方法统称为Windows验证。使用Windows验证时，浏览器提示用户输入用户名和密码，如图2-7所示。

图2-7 Windows验证的提示

为了实现Windows验证，可根据如下代码修改web.config文件：

然后，必须打开Internet Services Manager，并且为受保护的内容目录选择相关的属性。不要选中“anonymous access”，并且选择一种验证方法。

IIS提供4种标准验证方法：

n 基本验证

n 摘要验证

n 集成Windows验证

n 客户端证书映射

基本验证

基本验证通过提示Web站点访问者输入用户名和密码而起作用。该方法被广泛使用，因为大多数浏览器和Web服务器都支持该方法。该方法的优点如下：

n 它通过代理服务器进行工作。

n 它和几乎每一种因特网浏览器互相兼容。

n 它允许用户访问不在IIS服务器上的资源。

基本验证也有一些缺点：

n 信息以明文通过网络发送。信息使用base64编码方式编码（查看RFC 1521，了解更多有关base64编码方式的知识），但以一种未加密的格式发送。任何使用基本验证发送的密码都可以被轻松解码。

n 默认情况下，用户使用基本的验证必须具有本地登录权限。

n 基本验证易于受到重放攻击（replay attack）。

基本验证并没有加密用户证书，因此总是在加密的SSL会话上发送相关信息就显得尤为重要。使用基本验证进行验证的用户必须提供有效用户名和密码。该用户的账户可以是本地账户或域账户。默认情况下，IIS服务器看起来是本地化，或者是在用户账户的活动目录（活动目录）中。如果用户账户在某个域中（不是本地域），则用户必须在登录期间指定域名。该过程的语法是“域名\用户名”，其中“域名”指用户所在域的名称。当使用存储在活动目录中的账户时，也可以将基本的验证配置为使用用户主名称（UPN）。

为了防止将用户证书暴露给网络上的其他人，必须总是将SSL用于基本验证。注意，基本验证将使得浏览器将用户证书发送到相同站点或相同域上的每个页面，而不仅仅是登录页面。如果没有在每个页面上都使用SSL，则可以在网络上看到用户证书。防止在未受保护的内容上发送这些证书的一种方法是，为受保护的内容和未受保护的内容分别使用一个独特的域。参阅第4章，了解更多有关使用SSL的知识。

摘要验证

摘要验证（digest authentication）和基本验证有很多类似之处，但它克服了基本验证中的一些问题。摘要验证并不通过网络发送用户名和密码。摘要验证比基本的验证更为安全，但需要做更多的规划，以使其起作用。

摘要验证和基本验证的类似之处如下：

n 用户必须有本地登录权限。

n 两种方法都可通过防火墙。

与所有验证方法一样，摘要验证也有一些缺点：

n 用户只可以访问IIS服务器上的资源。证书不能被传递到另一台计算机。

n IIS服务器必须是域的一个成员。

n 所有的用户账户必须使用可逆的加密方法存储密码。

n 该方法只在Internet Explorer 5.0或更高版本中起作用。

n 在有限范围内，摘要验证容易受到重放攻击。

摘要验证是安全的，这得益于它通过网络传递验证信息所使用的方法。它绝对不会发送用户名和密码。相反，IIS使用消息摘要（或哈希）来验证用户的证书。为了使摘要验证起作用，必须使用可逆的加密算法在活动目录中存储所有的用户账户，这可能是一个潜在的风险。在针对用户账户启用该设置后，必须改变用户的密码以创建普通文本的副本。

摘要验证确实提供了更多的安全性，但对于大多数Web站点来说，这种方法的限制超出了它的优点。使用IIS时，一个有趣的特性是：当将验证头发送给客户时，它将在摘要验证之前发送一个基本验证头。许多因特网浏览器都使用它们遇到的第一个头，从而选择了较弱的基本验证。

集成Windows验证

集成Windows验证也是一种安全解决方案，并且它并不通过网络传送用户名和密码。该方法非常方便，这是因为：如果用户已经登录到域，并且拥有该站点的正确权限，则他将不会收到输入用户名和密码的提示。相反，IIS尝试使用用户的缓存证书进行验证。哈希缓存的证书，并且发送到IIS服务器进行验证。如果缓存证书没有正确的权限，则提示用户输入不同的用户名和密码。

根据客户端和服务器的配置，集成Windows验证使用Windows NT LAN Mangager（NTLM）或Kerberos进行验证。无法直接选择使用哪一种验证方法；IIS将根据客户端和服务器的配置自动选择一种方法。Web浏览器和IIS服务器通过协商验证头来商议使用哪一种方法。Kerberos和NTLM各有优缺点。Kerberos比NTLM更快、更安全。NTLM只验证客户端，而Kerberos则同时验证客户端和服务器，这样有助于防止电子欺骗（spoofing）。Kerberos也允许用户访问不在IIS服务器上的远程网络资源。NTLM则限制用户只能访问位于IIS服务器上的信息。

对于内联网Web服务器来说，Kerberos是首选的验证方法。然而，使用Kerberos而不使用NTLM的情况，必须满足下面的需求：

n 客户端和服务器都必须运行Windows 2000或更高版本。

n 客户端必须使用Internet Explorer 5或更高版本。

n 客户端和服务器必须与IIS服务器位于相同域中，或者位于可信域中。

集成Windows验证有一些限制：

n 它只工作于Internet Explorer 3.01或更高版本。

n 它无法通过防火墙起作用。客户端将在集成Windows哈希中使用防火墙的IP地址，导致验证请求失败。

客户证书映射

客户证书映射是将证书映射到用户账户的过程。通过活动目录或IIS可映射证书。这两种方法都需要安全套接字层（SSL，Secure Sockets Layer）。有3种类型的证书映射：

n 一对一映射

n 多对一映射

n UPN映射

证书映射是将证书链接到指定用户账户的过程。一般情况下，如果允许经过验证的用户访问内联网，要么创建一个用户账户，要么允许用户使用他的域账户登录。创建重复账户将消耗不必要的时间。然而，如果用户使用域账户，则必须考虑到他们的域密码所带来的安全风险。

为了提供更好的安全性并减少管理上的工作量，可以选择给每个用户发布一个证书。这些证书可用于验证用户的完整性。实际上，使用证书比使用用户账户更为有效，因为不需要连接到数据库就可以检查证书。分配证书比分配用户账户更为安全。此外，比起伪造证书，攻击者可以更容易地猜测或破解密码。

验证用户

如果要保护内联网应用程序的安全，并且已经控制了该应用程序的服务器和客户端配置，同时对应的客户端和服务器都在相同的域中，则集成Windows验证可能就是最佳的解决方案。对于公共Web站点，最广泛支持的方法是SSL连接上的基本验证。因为基本验证只有在使用SSL时才是安全的，可以在服务器上实施该策略。我们可以通过HTTP模块来完成，如图2-8（C#）和图2-9（VB.NET）所示。每当将验证请求发送到服务器时，这段代码将检查该请求是否使用基本验证，并且是通过SSL连接发送。如果这两个标准都不满足，这段代码将“403.4 SSL Required error”消息返回给客户端。

图2-8 阻塞没有使用SSL的基本验证（C＃）

图2-8 阻塞没有使用SSL的基本验证（C＃）（续）

图2-9 阻塞没有SSL的基本验证（VB.NET）

注意，HTTP模块中的代码只运行在由ASP.NET处理的文件上。如果希望ASP.NET处理所有的文件，则需要遵循“映射非ASP.NET资源”补充说明中的指示。

验证到操作系统或域的另一个问题是，无法直接控制哪一个账户用于登录。如果提供一个登录框，则任何拥有该系统上账户的人都可以尝试登录。他们可能无法访问资源，但却可以验证到服务器。攻击者将有机会对具有特权的账户（例如Administrator）进行暴力攻击。

根据网络和服务器配置，Windows验证也允许将攻击从Web服务器传播到内部网络上其他可信的域或服务器。Windows验证允许用户以“域\用户名”格式输入域限定的名称，以验证到其他可信域。如果攻击者知道另一个可信域（Web服务器可看到该域）的名称，就可以尝试验证到内部域，以传递攻击。当使用存储在活动目录中的账户时，也可以配置基本验证来权衡UPN，从而再次为数据传递攻击提供更多的机会。

使用Windows验证时，可能希望限制某些用户登录到服务器。可以使用文件或URL授权来防止访问，但这无法防止用户尝试进行验证——而只能防止用户访问内容。这两种方法都实施基于用户的访问，因此必须首先验证用户。如果不希望通过验证机制将具有特权的用户账户暴露给暴力攻击，则可以简单地彻底防止在Web应用程序中验证用户。实现这个目标的一种方法是通过HTTP模块，如图2-10（C#）和图2-11（VB.NET）所示。这段代码在发送验证请求时检查用户名，查看是否包含用户Administrator。如果包含的话，则返回“HTTP 401 error”消息。这将防止任何人试图以Administrator进行验证。