导读：
基本验证（Basic Authentication）
大多数人害怕使用基本验证，这是由于启用基本验证后用户所面对的界面所引起的：
选择该验证方式后，密码不经数据加密就在网络传送。某些想危害你的系统的安全的人员可以使用一个协议分析器（protocol analyzer）在验证过程中截获用户密码。用户验证的详细资料请参阅联机帮助。
你确信要继续?
这个消息的确像看起来的一样糟糕。用户名何密码使用64位（Base-64）编码。即使对于黑客新手，虽然他们仍然要访问你的网络并使用一个TCP/IP包探测器（TCP/IP packet-sniffer）截获网络协议包，64位的加密却是易于破解的。结果黑客们不大可能会攻击你的站点，除非你这里是一个非常吸引人的目标（比如银行）。
我所接触过的大多数Web管理员都了解挑战/响应验证和基本验证的差异，但还是互换性的对待它们。基本验证总是向用户显示对话框要求用户输入用户名和密码。然后输入的信息被发送到IIS，IIS使用该用户名和密码执行一个本地登录命令（Log on locally）命令在所在计算机进行本地登录。因为这时IIS已得到了该用户的密码，所以它能够响应远程系统的挑战信息，这样就消除了委托的问题。(一个实际位于Web服务器的用户使用基本验证，而使用挑战/响应的用户仍能够通过网络访问Web服务器)。实际上，用户权限“从网络访问该计算机（Access this computer from the network）”和“本地登录（Log on locally）”是需要特别设置的，而且也与所使用的验证方法有关。要设置这些权限，使用域用户管理器（User Manager for Domains）工具，然后在策略（Policies）菜单中选择用户权限（User rights）。
虽然有一些缺陷，但有两种环境还是应该使用基本验证：
你需要验证使用非Internet Explorer浏览器的用户。例如， Netscape Navigator只理解基本验证。如果你选择了挑战/响应验证和基本验证，对于Internet Explorer将一定会使用Windows NT挑战/响应验证，而对于Navigator则会选择基本验证。如果你的数据是敏感数据，这是一个严重的涉及安全的问题。
你的站点对用户进行验证，同时你的ASP页访问其它Windows NT计算机的资源。经典的方式是通过使用ActiveX数据对象（ActiveX Data Objects）的ASP页访问位于远程Windows NT计算机的数据库。为了避免委托的影响，应确保所有请求的资源位于IIS本身所在的计算机上，而如果这不现实的话，就使用基本验证。
普通验证场景
无论何时当使用Windows NT挑战/响应验证一个Internet用户时，当IIS使用UNC （Universal Naming Convention，统一命名约定）路径访问位于网络中或本地的Windows NT 资源时都要考虑委托这个因素。当然，所有的本地资源当该用户拥有正确的NTFS级权限时就能够访问。
UNC 路径
当一个ASP页的代码访问的数据库使用的是基于文件的数据源（比如Access的.MDB文件），而且位置是通过一个UNC路径确定时，会出现一个常见的有关委托的错误。即使资源位于本地，使用UNC标明位置会使Windows NT认为其位于网络中的其他某地。UNC路径由Windows NT网络子系统处理。Windows NT与其各组件有很大的分离，以致如果你逐渐进入网络子系统，直到其它涉及的Windows组件，你会位于网络之外。这导致了一个令人糊涂、但却相当有趣的情景：使用挑战/响应验证的IIS计算机正在访问使用UNC路径的本地资源。在效果上，它从自身请求验证，是无法完成请求的。要解决这个问题，应使用IIS计算机上的绝对路径（例如，C:/folder/resource.ext）。
委托，不!
另外还有一个与委托失败相仿，但实际与委托毫无关系的更为难以确定的有关安全的失败。它发生在一个三级计算机层次(浏览器到Windows NT/IIS服务器到Windows NT 远程资源)。要确定是否错误是委托相关的，应检查是否事务被验证。如果是，问题差不多确定就是委托相关的。不过，如果页面被匿名访问，问题可能是IIS计算机本地的匿名帐户造成的。这很容易发生，因为IUSR_machinename帐户是在本地创建的。IIS扮演IUSR_machinename帐户并尝试访问远程计算机上的资源。挑战信息被传送后，IIS使用IUSR_machinename密码散列值对挑战信息进行正确的加密。不过，由于远程信息会试图使用其本地SAM数据库和本地域控制器验证密码，而由于远程Windows NT 计算机和域控制器都没有记录该帐户，因此不可能验证这些信息。
要避免这个问题，可以尝试下面的方法：
在远程系统中创建一个复制的IUSR_machinename帐户，并确保具有相同的密码。如果在IIS服务器试图访问的计算机上存在一个相同的本地帐户，它不需要一个域控制器的帮助就能验证提交的散列值。即使这两个帐户是在物理上分离的帐户，如果它们的信息匹配，验证还是会发生。你能够侥幸使用这个技术是因为Windows NT所使用的散列算法会对不同用户的两个相同密码产生相同的密码散列值。在UNIX中，不会有这种情况。UNIX引入了一个被称为“salt”的值，这样具有相同密码的两个用户会产生不同的散列值。当你希望IUSR_machinename帐户只能访问你的站点的特定远程资源时，最好设置一个复制的本地帐户。如果某人能够饶过匿名帐户密码，他们也只能访问网络中存在本地帐户的计算机。当然，其缺点在于如果匿名用户需要访问多个远程资源，你会面临管理员的噩梦，因为所有的帐户及其密码必须同步保存。
设置匿名登录帐户为域帐户。要作到这一点，从本地IIS计算机上删除IUSR_machinename 帐户，并在域控制器上创建一个新帐户。然后进入Internet服务管理器的WWW属性对话框，在用户名（Username）文本框中以Domain/Username格式(例如，BigDomain/JoeUser)输入用户信息。管理员这是最简单的方法，但是当帐户信息被危及后，侵入者将在网络中获得巨大的访问权限。由于一些原因，我曾经和许多担心IUSR_machinename帐户成为黑客攻击目标的网络管理员进行过讨论。实际上，盗用一个匿名登录帐户名和密码不会比盗用CEO的帐户和密码容易，所以我更喜欢这种方法。
SQL Server 具有独一无二的能力实现与其它计算机的非验证联接，可以有效地饶过Windows NT安全。如果安全问题并不是大问题(小型、私有Intranet通常非常安全)，你可能希望通过TCP/IP联接到SQL server。SQL server会监视网络传输并对TCP/IP请求直接作出反应，将taking Windows NT out of the loop. SQL具有自己的安全层，所以使用该功能你仍然能够实现一个良好的安全配置。要使用该功能，在安装SQL时在Security对话框中选择TCP/IP sockets。
是否需要“安全对话框”的问题!
一些Web开发人员不希望用户在每次访问他们的站点时都必须输入姓名和密码。所以到底何时用户需要提示一个对话框输入他（她）的姓名和密码呢?
当使用Windows NT 挑战/响应验证时，Internet Explorer将自动而且不可视的发送当前用户的登录名、域名和散列值到Web服务器。Internet Explorer不需要请求就进行这些操作，因为发送加密的挑战信息不会带来任何的安全风险。在这时会发生两件事：
如果IIS计算机发送的信息能够被域控制器进行验证，用户不需要可视化的提示就能得到验证。
如果IIS未能识别浏览器发送的域名，那它将不知道需要验证的信息来自何处。这种情况对于Internet用户比Intranet用户更为常见，因为在家中的用户很少位于一个域中(而且即使如果是域用户，其域控制器可能也无法被IIS计算机访问)。Internet Explorer将提示用户输入新的姓名和密码，从效果上讲，"给我一些能够使用的信息（Give me some information that I can use）。" 如果一个在家工作的雇员试图访问一个设置安全的站点，他将需要输入他的姓名(按照BigDomain/JoeUser的形式)和密码以使IIS能够得到正确的域信息。在验证Internet的用户时以这种方式明确说明域名总是必要的。
在基本验证方式中，用户将被提示出现一个登录对话框。你或许可以猜测一下原因。你将要做的事可能会危及你的Windows NT帐户和密码。所有的浏览器都明确的指出：如果你输入了信息并按下OK，你必须知道你在做什么。我个人在一个安全的集成网络中使用基本验证并没有问题，但如果没有诸如Secure Sockets Layer（安全套接字）的附加安全层我将不会在Internet上使用基本验证。Secure Sockets Layer在使用HTTPS://而不是HTTP://的特殊配置Web服务器上被调用。用户再次需要明确说明所提交的带有某个域控制器的信息。
黑客与你的站点
在我更进一步的说明之前，我需要声明不做承诺：是的，积极的年轻黑客会读到这篇文章并得到启发，但是，相信我，对于黑客有许多比本文更好的信息来源。确保你的站点真正安全的最佳方法是了解站点的弱点何在(没有人能比黑客更了解站点的薄弱之处)。在一个Web站点上有几个区域可能被黑客尝试攻击或浏览。很明显，在他们的手边拥有一个具有管理员权限的用户名和密码是最佳的方法。得到一个用户的密码散列值也一样好，因为密码散列值有时可作为“密码等效物”使用。密码散列值可通过加密挑战信息而用于回答挑战。这样做会赋予入侵者“从网络访问该计算机（Access this computer from the network）”权限。要被赋予“本地登录（Log on locally）”权限，入侵者仍然需要实际的密码。
一些程序已经被编写出来特别用于抽取和破解Windows NT 域控制器SAM数据库的密码散列值。PWDump.exe和NTCrack.exe 都是在Internet上免费的且被系统管理员和黑客使用的该类程序。PWDump.exe程序用于将SAM数据库的用户散列值和帐户信息转写到一个文本文件中。系统管理员使用PWDump 在混合环境中（比如UNI
本文转自
http://study.qqcf.com/web/245/29828.htm
基本验证（Basic Authentication）
大多数人害怕使用基本验证，这是由于启用基本验证后用户所面对的界面所引起的：
选择该验证方式后，密码不经数据加密就在网络传送。某些想危害你的系统的安全的人员可以使用一个协议分析器（protocol analyzer）在验证过程中截获用户密码。用户验证的详细资料请参阅联机帮助。
你确信要继续?
这个消息的确像看起来的一样糟糕。用户名何密码使用64位（Base-64）编码。即使对于黑客新手，虽然他们仍然要访问你的网络并使用一个TCP/IP包探测器（TCP/IP packet-sniffer）截获网络协议包，64位的加密却是易于破解的。结果黑客们不大可能会攻击你的站点，除非你这里是一个非常吸引人的目标（比如银行）。
我所接触过的大多数Web管理员都了解挑战/响应验证和基本验证的差异，但还是互换性的对待它们。基本验证总是向用户显示对话框要求用户输入用户名和密码。然后输入的信息被发送到IIS，IIS使用该用户名和密码执行一个本地登录命令（Log on locally）命令在所在计算机进行本地登录。因为这时IIS已得到了该用户的密码，所以它能够响应远程系统的挑战信息，这样就消除了委托的问题。(一个实际位于Web服务器的用户使用基本验证，而使用挑战/响应的用户仍能够通过网络访问Web服务器)。实际上，用户权限“从网络访问该计算机（Access this computer from the network）”和“本地登录（Log on locally）”是需要特别设置的，而且也与所使用的验证方法有关。要设置这些权限，使用域用户管理器（User Manager for Domains）工具，然后在策略（Policies）菜单中选择用户权限（User rights）。
虽然有一些缺陷，但有两种环境还是应该使用基本验证：
你需要验证使用非Internet Explorer浏览器的用户。例如， Netscape Navigator只理解基本验证。如果你选择了挑战/响应验证和基本验证，对于Internet Explorer将一定会使用Windows NT挑战/响应验证，而对于Navigator则会选择基本验证。如果你的数据是敏感数据，这是一个严重的涉及安全的问题。
你的站点对用户进行验证，同时你的ASP页访问其它Windows NT计算机的资源。经典的方式是通过使用ActiveX数据对象（ActiveX Data Objects）的ASP页访问位于远程Windows NT计算机的数据库。为了避免委托的影响，应确保所有请求的资源位于IIS本身所在的计算机上，而如果这不现实的话，就使用基本验证。
普通验证场景
无论何时当使用Windows NT挑战/响应验证一个Internet用户时，当IIS使用UNC （Universal Naming Convention，统一命名约定）路径访问位于网络中或本地的Windows NT 资源时都要考虑委托这个因素。当然，所有的本地资源当该用户拥有正确的NTFS级权限时就能够访问。
UNC 路径
当一个ASP页的代码访问的数据库使用的是基于文件的数据源（比如Access的.MDB文件），而且位置是通过一个UNC路径确定时，会出现一个常见的有关委托的错误。即使资源位于本地，使用UNC标明位置会使Windows NT认为其位于网络中的其他某地。UNC路径由Windows NT网络子系统处理。Windows NT与其各组件有很大的分离，以致如果你逐渐进入网络子系统，直到其它涉及的Windows组件，你会位于网络之外。这导致了一个令人糊涂、但却相当有趣的情景：使用挑战/响应验证的IIS计算机正在访问使用UNC路径的本地资源。在效果上，它从自身请求验证，是无法完成请求的。要解决这个问题，应使用IIS计算机上的绝对路径（例如，C:/folder/resource.ext）。
委托，不!
另外还有一个与委托失败相仿，但实际与委托毫无关系的更为难以确定的有关安全的失败。它发生在一个三级计算机层次(浏览器到Windows NT/IIS服务器到Windows NT 远程资源)。要确定是否错误是委托相关的，应检查是否事务被验证。如果是，问题差不多确定就是委托相关的。不过，如果页面被匿名访问，问题可能是IIS计算机本地的匿名帐户造成的。这很容易发生，因为IUSR_machinename帐户是在本地创建的。IIS扮演IUSR_machinename帐户并尝试访问远程计算机上的资源。挑战信息被传送后，IIS使用IUSR_machinename密码散列值对挑战信息进行正确的加密。不过，由于远程信息会试图使用其本地SAM数据库和本地域控制器验证密码，而由于远程Windows NT 计算机和域控制器都没有记录该帐户，因此不可能验证这些信息。
要避免这个问题，可以尝试下面的方法：
在远程系统中创建一个复制的IUSR_machinename帐户，并确保具有相同的密码。如果在IIS服务器试图访问的计算机上存在一个相同的本地帐户，它不需要一个域控制器的帮助就能验证提交的散列值。即使这两个帐户是在物理上分离的帐户，如果它们的信息匹配，验证还是会发生。你能够侥幸使用这个技术是因为Windows NT所使用的散列算法会对不同用户的两个相同密码产生相同的密码散列值。在UNIX中，不会有这种情况。UNIX引入了一个被称为“salt”的值，这样具有相同密码的两个用户会产生不同的散列值。当你希望IUSR_machinename帐户只能访问你的站点的特定远程资源时，最好设置一个复制的本地帐户。如果某人能够饶过匿名帐户密码，他们也只能访问网络中存在本地帐户的计算机。当然，其缺点在于如果匿名用户需要访问多个远程资源，你会面临管理员的噩梦，因为所有的帐户及其密码必须同步保存。
设置匿名登录帐户为域帐户。要作到这一点，从本地IIS计算机上删除IUSR_machinename 帐户，并在域控制器上创建一个新帐户。然后进入Internet服务管理器的WWW属性对话框，在用户名（Username）文本框中以Domain/Username格式(例如，BigDomain/JoeUser)输入用户信息。管理员这是最简单的方法，但是当帐户信息被危及后，侵入者将在网络中获得巨大的访问权限。由于一些原因，我曾经和许多担心IUSR_machinename帐户成为黑客攻击目标的网络管理员进行过讨论。实际上，盗用一个匿名登录帐户名和密码不会比盗用CEO的帐户和密码容易，所以我更喜欢这种方法。
SQL Server 具有独一无二的能力实现与其它计算机的非验证联接，可以有效地饶过Windows NT安全。如果安全问题并不是大问题(小型、私有Intranet通常非常安全)，你可能希望通过TCP/IP联接到SQL server。SQL server会监视网络传输并对TCP/IP请求直接作出反应，将taking Windows NT out of the loop. SQL具有自己的安全层，所以使用该功能你仍然能够实现一个良好的安全配置。要使用该功能，在安装SQL时在Security对话框中选择TCP/IP sockets。
是否需要“安全对话框”的问题!
一些Web开发人员不希望用户在每次访问他们的站点时都必须输入姓名和密码。所以到底何时用户需要提示一个对话框输入他（她）的姓名和密码呢?
当使用Windows NT 挑战/响应验证时，Internet Explorer将自动而且不可视的发送当前用户的登录名、域名和散列值到Web服务器。Internet Explorer不需要请求就进行这些操作，因为发送加密的挑战信息不会带来任何的安全风险。在这时会发生两件事：
如果IIS计算机发送的信息能够被域控制器进行验证，用户不需要可视化的提示就能得到验证。
如果IIS未能识别浏览器发送的域名，那它将不知道需要验证的信息来自何处。这种情况对于Internet用户比Intranet用户更为常见，因为在家中的用户很少位于一个域中(而且即使如果是域用户，其域控制器可能也无法被IIS计算机访问)。Internet Explorer将提示用户输入新的姓名和密码，从效果上讲，"给我一些能够使用的信息（Give me some information that I can use）。" 如果一个在家工作的雇员试图访问一个设置安全的站点，他将需要输入他的姓名(按照BigDomain/JoeUser的形式)和密码以使IIS能够得到正确的域信息。在验证Internet的用户时以这种方式明确说明域名总是必要的。
在基本验证方式中，用户将被提示出现一个登录对话框。你或许可以猜测一下原因。你将要做的事可能会危及你的Windows NT帐户和密码。所有的浏览器都明确的指出：如果你输入了信息并按下OK，你必须知道你在做什么。我个人在一个安全的集成网络中使用基本验证并没有问题，但如果没有诸如Secure Sockets Layer（安全套接字）的附加安全层我将不会在Internet上使用基本验证。Secure Sockets Layer在使用HTTPS://而不是HTTP://的特殊配置Web服务器上被调用。用户再次需要明确说明所提交的带有某个域控制器的信息。
黑客与你的站点
在我更进一步的说明之前，我需要声明不做承诺：是的，积极的年轻黑客会读到这篇文章并得到启发，但是，相信我，对于黑客有许多比本文更好的信息来源。确保你的站点真正安全的最佳方法是了解站点的弱点何在(没有人能比黑客更了解站点的薄弱之处)。在一个Web站点上有几个区域可能被黑客尝试攻击或浏览。很明显，在他们的手边拥有一个具有管理员权限的用户名和密码是最佳的方法。得到一个用户的密码散列值也一样好，因为密码散列值有时可作为“密码等效物”使用。密码散列值可通过加密挑战信息而用于回答挑战。这样做会赋予入侵者“从网络访问该计算机（Access this computer from the network）”权限。要被赋予“本地登录（Log on locally）”权限，入侵者仍然需要实际的密码。
一些程序已经被编写出来特别用于抽取和破解Windows NT 域控制器SAM数据库的密码散列值。PWDump.exe和NTCrack.exe 都是在Internet上免费的且被系统管理员和黑客使用的该类程序。PWDump.exe程序用于将SAM数据库的用户散列值和帐户信息转写到一个文本文件中。系统管理员使用PWDump 在混合环境中（比如UNI
本文转自
http://study.qqcf.com/web/245/29828.htm
扫一扫
761
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
