测试其他脆弱的认证渠道 (OTG-AUTHN-010)

综述

有时甚至可能会发生主要的认证机制不包含任何漏洞，但是可能在其他合法的认证用户渠道中存在漏洞。测试应该被实施在识别其他的渠道，以及在测试范围内识别漏洞。

其他用户交互渠道可能被利用绕过主要交互通道，或暴露一些有助于攻击者攻击主要通道的信息。有些渠道可能通过使用不同的主机名或路径来区分自己。例如：

• 标准网站
• 为移动或特定设备优化的网站
• 为无障碍访问优化的网站
• 其他国家和语言网站
• 使用相同用户账号的平行网站（如同一个组织中提供不同功能的另一个网站，共享用户账户的伙伴网站）
• 开发、测试、终端用户集成测试和标准站点的不同阶段版本的网站

他们可能在其他类型的应用或业务逻辑中使用：

• 移动设备APP
• 桌面应用
• 呼叫中心操作员
• 交互语音服务或电话系统

注意，这个测试注重于其他认证渠道，一些其他的认证可能以不同内容通过相同网站内访问到，也应该包含在测试范围之中。这里不再深入讨论，他们应该在信息收集中被识别，并在主要认证测试环节中被测试。例如：

• 积极改进或维护降级导致的功能变化
• 不使用cookies的站点
• 不使用JavaScritp的站点
• 不使用插件如Flash和Java的站点

甚至有时测试范围不允许测试其他的认证渠道，他们的存在也应该写入测试文档之中。他们可能会破坏认证机制的可靠程度，可能成为下一次测试的前提。

案例

主站点是：

 http://www.example.com

认证功能总是在TLS层中发生：

 https://www.example.com/myaccount/

但是，有移动优化的网站的存在，他并使用TLS来访问，并且存在一个更加弱化的密码恢复机制：

 http://m.example.com/myaccount/

如何测试

理解主要的网站机制

完整测试网站主要认证功能。这应该识别出如何账户被使用、创建或改变，密码如何被恢复、重置或改变。此外，任何提升权限的认证和认证保护措施应该被了解。这些是用来与其他访问渠道对比的前提。

识别其他访问渠道

其他访问渠道可以从下列方法中找到：

• 读取站点内容，特别是主页、联系我们、帮助页面、技术支持和FAQ、买家须知、私人提示、robots.txt文件和任何sitemap.xml文件。
• 搜索HTTP代理日志，先前信息收集和测试的记录，在URL路径或主体内容中搜索类似"mobile"、"android"、"blackberry"、"ipad"、"iphone"、"mobile app"、"e-reader"、"wireless"、"auth"、"sso"、"single sign on"之类的字符串。
• 使用搜索引擎来查找相同组织的不同网站内容，或使用相同域名发现类似主页内容或存在认证机制的也没。

对于每一个可能的访问渠道，确认他们是不是共享了用户账户，或提供相同或类似的访问功能。

枚举认证功能

对于每一个用户账户和功能共享的其他访问渠道，识别出主要渠道的认证功能是否在这些地方也可用，或是有额外的方式存在。可能使用下面的表格来记录比较方便：

在这里例子中，移动设备拥有额外的“修改密码”的功能，并不提供“登出”功能。有限的任务也能通过电话呼叫中心完成。呼叫中心非常有趣，因为他对于身份鉴别的核查可能弱与主要网站，可能被用于帮助攻击者对抗用户账户。

在枚举这些渠道的同时，也值得注意会话管理情况，以防发生重叠现象（比如同一父域下的cookie发送范围，不同渠道的并行会话情况）。

审查并测试

测试报告应该要提及这些其他的访问渠道，即使他们仅仅是标记为“仅信息”或“测试范围之外”。在一些情况下，测试范围可能包括这些访问渠道（如，因为他是目标主机名下另一个路径），或可能在与客户讨论之后加入测试范围。如果允许并收取测试，所有的在本篇指南中提到的额外访问渠道测试应该被实施，并与主要访问方式做对比。

相关测试用例

其他认证测试的测试用例应该被利用。

整改措施

确保认证策略被一致性地应用在所以访问渠道，保证他们相同程度的安全。