IIS6.0支持的身份验证安全机制有4种验证方法，其中安全级别最高的验证方法是（64）。

Microsoft的Web服务器产品为Internet Information Services（IIS），IIS是允许在公共Intranet或Irternet上发布信息的Web服务器，是目前最流行的Web服务器产品之一。ⅡS提供了一个图形界面的管理工具，称为Internet服务管理器，可用于监视配置和控制Internet服务。

IIS是一种Web服务组件，其中包括Web服务器、FTP服务器、NNTP服务器和SMTP服务器，分别用于网页浏览、文件传输、新闻服务和邮件发送等方面，它使得在网络上发布信息成为一件很容易的事。IIS提供ISAPI（Intranet Server API）作为扩展Web服务器功能的编程接口；同时，它还提供一个Internet数据库连接器，可以实现对数据库的查询和更新。

身份认证技术的定义

身份认证（Identity Authentication）是整个信息安全体系的基础，访问控制是对信息系统资源进行保护的重要措施，也是计算机系统最重要和最基础的安全机制。

身份认证是对系统中的主体进行验证的过程，用户必须提供“他是谁”的证明。

身份认证技术分为以下几类。

. 从是否使用硬件来看，可以分为软件认证和硬件认证。

. 从认证需要验证的条件来看，可以分为单因子认证和双因子认证。

. 从认证信息来看，可以分为静态认证和动态认证。

. 从认证手段来看，可以分为基于用户所知道的秘密（如口令、个人识别号或密钥）、基于用户所拥有的令牌（如信用卡、智能卡、印章）、基于用户本身的生物特征（如语音特征、笔记特征或指纹）。

根据控制手段和具体目的的不同，人们将访问控制技术分为几个不同的级别，包括入网访问控制、网络权限控制、目录级控制、属性控制以及网络服务器的安全控制等。

访问控制的目的是防止非法用户进入系统及合法用户对系统资源的非法使用，也就是说，访问控制的基本任务是限制访问主体对访问客体的访问权限，保证主体对客体的所有直接访问都是经过授权的。

访问控制涉及的领域很广，方法也很多，根据访问策略的不同，访问控制可以分为自主访问控制（Discretionary Access Control）、强制访问控制（Mandatory Access Control）和基于角色的访问控制（Role Based Access Control）。

自主访问控制是指对某个客体具有拥有权（或者控制权）的主体能够将对客体的一种访问权或者多种访问权自主地授予其他主体，并在随后的任何时刻都能将这些权限回收。

强制访问控制是指计算机系统根据使用系统的机构事先确定的安全策略，对用户的访问权限进行强制性的控制。

基于角色的访问控制的基本思想是在用户和访问权限之间引入角色的概念，将用户和角色联系起来，通过对角色的授权控制用户对系统资源的访问。

身份验证

检查应用程序验证调用者身份的方法，在何处使用身份验证，如何确保凭据在存储中或通过网络传递的安全。身份验证中的漏洞可能导致应用程序易受哄骗攻击、词典攻击、会话劫持等。下表重点列出了常见的身份验证漏洞。

常见的身份验证漏洞

测试中需要考虑下列问题，确定在应用程序进行身份验证的方法中的潜在漏洞。

. 是否区分公共访问和受限访问。

如果应用程序既有不要求身份验证的公共区域，也有要求身份验证的受限区域，检查站点设计区分二者的方法。必须为受限的页和资源使用单独的子文件夹，然后在IIS中将它们配置为要求SSL来确保安全。这种方法允许只在需要的地方使用SSL来确保敏感数据和身法验证cookie的安全性，从而避免了因在整个站点中使用SSL而造成的附加性能负担。

. 是否明确服务账户要求。

设计应明确连接不同资源（包括数据库、目录服务和其他类型的网络资源）的服务账户范围。设计中不能使用单个的、有高度特权的账户（有足够的权限连接多种不同类型的资源）。

①设计是否要求特权最少的账户。

检查设计并准确标识各账户执行特定功能所需的特权，然后在任何情况下都使用特权最少的账户。

②应用程序是否要维护服务账户凭据。

如果是，确保加密这些凭据，然后保存在受限的位置中。例如，保存在有受限访问控制列表（ACL）的注册表项。

. 如何验证调用者身份。

测试时考虑与调用者身份验证相关的下列事项。具体事项由设计中使用的身份验证类型决定。

①是否在网络中传递明文凭据。如果使用表单或基本身份验证（或使用Web服务并在SOAP头中传递凭据），确保使用SSL来保护传输中的凭据。

②是否实现自己的用户存储。如果是，检查用户凭据的存储位置和存储方式。一种常见错误是将明文或加密密码保存在用户存储中。实际上，必须保存密码的哈希值来进行身份验证。

如果根据SQL Server用户存储验证凭据，密切注意用户名和密码的输入。检查是否存在恶意注入的SQL字符。

③是否使用表单身份验证。如果是，除使用SSL保护凭据外，还应使用SSL来保护身份验证cookie。此外，还要检查设计是否使用受限的会话生存期来抵御cookie重播攻击，并确保加密cookie。

. 如何验证数据库的身份。

如果应用程序要连接数据库，检查使用的身份验证机制、打算使用的账户（一个或多个），以及如何在数据库中授权应用程序。

明确下列问题有助于对数据库身份验证进行评价。

①是否使用SQL身份验证。

在理想情况下，设计使用Windows身份验证来连接SQL Server，因为这种方法本身更加安全。如果使用SQL身份验证，检查在网络中和数据库连接字符串中确保凭据安全的方法。

如果网络基础结构不提供IPSec加密通道，确保在数据库中安装服务器证书来提供自动SQL凭据加密。此外，还要检验确保数据库连接字符串安全的方法，因为这些字符串中包含SQL账户的用户名和密码。

②是否使用进程账户。

如果使用应用程序的进程账户并使用Windows身份验证连接SQL服务器，应在设计中使用特权最少的账户。本地ASP.NET账户便是为此提供的，尽管对于本地账户来说，用户需要在数据库服务器上创建一个相同的账户。

如果打算使用域账户，首先确保它是特权最少的账户，然后打开相关的端口来确保所有相关防火墙都支持Windows身份验证。

③是否使用服务账户。

如果设计要求使用多个身份来支持数据库中的高粒度授权，则需要检查保存账户凭据（在理想情况下，这些凭据使用数据保护API（DPAPI）加密并保存在安全注册表项中）的方法，以及使用服务身份的方法。

此外，还要检查使用哪些进程通过该服务账户创建模拟的安全上下文。该操作不应由Microsoft Windows 2000中的ASP.NET应用程序进程来完成，因为它将强制提升进程账户的特权，并授予“作为操作系统的一部分”特权。这种情况必须尽量避免，它将大大增加风险。

④是否考虑使用匿名Internet用户身份。

对于使用表单或Passport身份验证的应用程序而言，可为各个程序配置单独的匿名用户账户。然后，启用模拟并使用匿名身份来访问数据库。该方法适于对同一服务器的不同应用程序进行单独的授权和身份跟踪。

⑤是否使用原始用户身份。

如果设计要求模拟原始调用者，必须考虑该方法是否能提供足够的伸缩性，因为连接池是无效的。另一种备选方法是，通过受信的查询参数在应用程序级流动原始调用者身份。

⑥如何保存数据库连接字符串。

如果数据库连接字符串硬编码，或以明文形式保存在配置文件或COM+目录中，则很容易受到攻击。实际上，应加密它们，然后限制对加密数据的访问。

. 是否强制使用强账户管理措施。

如果应用程序使用Windows身份验证，Windows安全策略将强制使用强密码、受限登录和其他最佳账户管理策略。其他情况，则由应用程序层负责这些措施。测试要考虑与应用程序账户管理相关的下列问题。

①应用程序是否强制使用强密码。

例如，ASP.NET Web页是否使用正则表达式来验证密码复杂性规则。

②是否限制失败登录的次数。

这样做有助于对抗词典攻击。

③是否在故障发生后公开过多的信息。

确保不显示类似“不正确的密码”这样的消息，因为它将告诉恶意用户：用户名是正确的。结果，恶意用户便可集中精力破解密码。

④是否强制定期更改密码。

如果不强制定期更改密码，用户极有可能不更改自己的密码，结果风险更高。

⑤是否能在泄露发生时迅速禁用账户。

如果账户泄露，是否能方便地禁用账户来防止攻击者继续使用账户。

⑥应用程序是否记录登录企图。

记录失败的登录企图是检测攻击者试图侵入的有效方法。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5