|
前言
有安全意识的人肯定不会为所有的网站设置同样的密码。为了提高一站一密码的安全系数，你可能会使用到密码管理器。不过刚开始使用时可能会有一丝不安，毕竟它将所有的密码都放在了同一个地方，而且很多密码管理器都会同步到所有设备和云上。在这篇文章中，作者说明了很多密码管理器中都包含一个主要漏洞，而且这个漏洞如被利用可自动填充密码字段!由于作者写作本文是在2014年，因此可能所述的攻击向量已被关闭(如果你知道相关的更新报告，请在评论区留言)，不过我认为这些攻击的变种仍然还在。
一言以蔽之：不要使用自动填充功能。
邪恶的咖啡店攻击者
攻击者应该能够实施主动的中间人攻击。但是要窃取网站的凭证，也没有硬性要求用户必须直接明确地访问或者登录到某个网站。咖啡店(举个例子)的一个恶意wifi路由器就够了：连接到这个路由器，你的密码就不翼而飞了。
我们将这种攻击者称为“邪恶的咖啡店攻击者”。这些攻击只需要对网络路由器拥有临时控制，而且实施起来更容易，因此很可能在现实生活中发生。在我们所讲述的很多攻击中，用户都无需跟受害者网站交互，而且用户不会意识到密码已被提取。
扫描攻击
基本的扫描(sweep)攻击会攻陷所有支持自动填充密码字段的密码管理器，因为目标用户连接到了由攻击者控制的WiFi热点。
当用户启动浏览器时，浏览器会被重定向到一个标准的热点登录页面，该页面要求获取用户关于标准使用条款的同意。这种行为常见于公共热点。然而，用户没有意识到的是，登录页面包含着实施攻击的不可见元素。
换句话说，等到你查看完整加载的登录页面时，你的多数凭证可能已经不见了。在测试中，每秒可被提取的密码数量是10个左右。
大体来讲，攻击者有三种使用登录页面的方法来扫描密码：
1. 在iFrame扫描攻击中，登录页面包含指向多个目标站点任意页面的不可见内嵌框架。当浏览器加载这些框架时，攻击者会向它们注入一个登录表单和javascript(详细方法看下文)。自动填充密码管理器会将用户密码填入相应的字段。
2. 攻击者不会使用内嵌框架，而是使用多个窗口。通过要求在用户能够获取访问wifi网络之前打开窗口，用户会禁用任何弹出阻拦。虽然多个窗口要比不可见的内嵌框架更惹人注意，但是注入的javascript能够将它们最小化或将它们移动到屏幕边缘。密码被盗后，窗口就会马上被关闭。
3. 第三种方法是使用重定向链。当用户请求某个页面时，攻击者就会以某个站点的重定向作为响应，攻击者正是凭此来获悉密码。被注入的javascript增加一个登录表单并隐藏页面详情。一旦密码管理器自动填充了密码且密码被提取，浏览器就会被重定向至下一个目标站点，以此循环往复，最终加载到用户原来请求的页面。而用户看到的不过是一个缓慢的wifi连接。
下列表格展示了截止2014年被测试的密码管理器，它们均易受扫描攻击。
注：上表是扫描攻击的漏洞。“+”表示漏洞没有限制。HTTPS表示漏洞仅存在于HTTPS页面。Single代表每个高级页面加载中有一个站点易受攻击。SO表示当包含内嵌框架的页面跟内嵌框架中的目标页面是同源时的漏洞。
注入
扫描攻击依靠的是攻击者通过篡改网络流量而修改受害者网站页面的能力。当易受攻击的页面就是登录页面本身时，攻击最容易实施。然而，只要有任何跟登录页面同源的页面就足够了，因为所有关联的密码管理器都通过域名保存密码而忽视登录页面的路径。
实施攻击的一个简单方法就是在HTTP协议下提供登录表单的站点(不良实践)，而且仅在提交时使用HTTPS。截止2013年10月份，在Alex排名前500的站点中，有17%的站点都是这么做的。目前情况应该好点了，但由于没有数据，也无法下定论。
任何一个通过HTTP获取动态内容的HTTPS网页都易受攻击(不过多数浏览器会实施拦截)。受害者网站任意网页上的任何XSS漏洞也会起作用(即便登录页面用的是HTTPS协议)。实际上网站上任何位置的XSS漏洞即使在不需要恶意WiFi的情况下都能触发攻击——只要网络攻击者能够诱骗用户访问受攻击者控制的网站即可。
损坏的HTTPS链接(例如损坏的证书)也会导致漏洞的出现，因为攻击者能够使用一个自签名证书作为修改后的登录页面。浏览器会发出告警，但用户通常都会选择忽视告警信息(尤其是当告警出现在登录WiFi网络时，或者至少用户是这么认为的)。
嵌入式设备更是如此。嵌入式设备会通过HTTP提供登录页面，它们一般是在受WiFi加密保护的私有网络上或者是通过HTTPS提供登录页面但使用自签名证书的家庭路由器。
密码提取
一旦攻击者页面的javascript获得目标密码，提取就容易多了。其中一种方法是加载一个不可见的内嵌框架并将凭证作为参数通过;另一种方法是修改登录表单的动作使其提交到受攻击者控制的站点。
如果密码管理器不支持自动填充呢?
到现在为止，我们提到的攻击都是当用户没有跟登录表单交互时，使用密码管理器的自动填充功能起作用。然而，我们提到的密码提取技术跟登录表单如何填充并没有关系。如果用户的密码管理器要求用户输入密码，那么攻击者就能够诱骗用户在无意识的情况下跟登录表单交互，一旦表单填充完毕，可使用相同的提取技术窃取密码。
作者描述了一种能够在这种场景下起作用的点击劫持，尽管我们现在只限于一次只窃取一个密码的方式。
密码管理器中的支持弱点
密码管理器除了自动填充功能外，还有其它一些行为也能帮助攻击者，这些行为的目的是尝试变得更加强大以应对站点实现详情中的变化。下表是一个简短总结。 
注：密码管理器的自动填充行为(自动化自动填充、手动自动填充或未填充)取决于协议 (http/https)、自动完成属性、跟协议相关的用于当前页面的表单动作和保存密码时使用的表单动作。Manual
autofilling(手动自动填充)是指完成某些用户交互后自动填充密码如点击或触摸其中的一个表单字段。No
fill(未填充)是指没有自动填充密码。倒数第二列是指当密码字段的自动完成属性被设置为off时的自动填充行为。最后一列是指不良HTTPS连接状态下针对加载的一个登录页面后的自动填充行为。
防御
主要的防御手段是要求安全填充，只需要一个被修改的浏览器就足够了(以及需要一个被修改的密码管理器与之相对应)。
如果一个登录页面是通过HTTP加载的但却通过HTTPS提交，那么一旦登录表单填上了用户的密码，那么浏览器或密码管理器实现就无法提供安全性，因为JavaScript能够直接从表单读取密码或者更改表单动作，以便提交到由攻击者托管的密码窃取页面。安全填充的目标是即使攻击者将恶意JavaScript注入登录页面，密码管理器自动填充的密码还是安全的，前提条件是表单是通过HTTPS提交的。
安全填充要求：
1. 从当用户名和密码首次被保存开始起，密码管理器要存储在登录表单中显示的行为。
2. 当登录表单由密码管理器自动填充时，JavaScript无法读取该表单(因此要有被修改的浏览器)。
3. 如果在自动填充正在进行过程中，用户名或密码字段被(用户或JavaScript)修改，自动填充会中止从密码字段中清除密码并再次让字段变为可读。
4. 一旦被自动填充的表单提交，而且JavaScript运行之后，浏览器就会检查表单的行为是否跟存储的一致，只有在一致的情况下才会提交表单。
需要注意的是，这也意味着，比如，我们需要处理起始注册页面，尤其是当它们经常会包含客户端对密码长度进行校验(要求js权限)时。
我们将研究结果披露给了密码管理器厂商，并提出对自动填充策略的一些改变。从我们的研究来看，LastPass不会在内嵌框架中自动填充密码，而iPassword也不再为HTPP页面提供从HTTPS页面填充密码的服务。
从此处可了解关于为何iPassword为何不提供自动填充功能的内容以及关于扫描攻击的讨论。
|
