在浏览器上，我们的隐私都是如何被泄漏的？

关键时刻，第一时间送达！

近日，两个利用隐藏登录表单收集登录信息的网络跟踪服务被彻底披露，分别是 Adthink（audienceinsights.net）和 OnAudience（behavioraorangine.com）。本文就将介绍第三方脚本如何利用浏览器的内置登录管理器（也称为密码管理器），在没有用户授权的情况下检索和泄露用户信息的。

事实上，密码管理器的潜在漏洞早已为人所知，过去的漏洞多是因为跨站点恶意脚本（XSS）攻击所造成的的密码泄漏。但在分析了五万个网站后，我们没有发现密码被窃取的情况，反而发现了跟踪脚本被滥用，导致用于构建跟踪标识符的电子邮件地址被大量提取。

上图显示了这一过程：首先，用户填写页面上的登录表单，并要求浏览器保存登录信息（跟踪脚本不在登录页面上显示）。然后，用户访问含有第三方跟踪脚本的同一网站上的另一个页面。跟踪脚本就会自动插入一个不可见的登录表单，该表单由密码管理器自动填写。第三方脚本通过读取填充的表单来检索用户的电子邮件地址，并将电子邮件地址发送给第三方服务器。

所有主流浏览器都有内置的登录管理器，可以自动保存并自动填写用户名和密码数据，使登录体验更加顺畅。所以登录表单自动填写，不管表单是否可见，而且通常不需要用户交互。在我们的测试中，Chrome 不会自动填充密码字段，除非用户点击或触摸页面。所以，对于密码管理器中保存的用户名（通常是电子邮箱地址）和密码，第三方脚本可以创建表单并自动填充。

为什么要收集电子邮件地址？一方面，因为电子邮件地址是唯一的，是一个很好的跟踪标识符。另一方面，用户的电子邮件地址几乎不会改变，使用隐私浏览模式或切换设备清除 Cookie 也不能阻止跟踪。此外，电子邮件地址可用于连接设备和移动应用程序中的在线配置文件，也可以作为 Cookie 清除前后浏览历史记录配置文件之间的链接。

通过密码管理器获取用户信息

“智能广告”和“大数据营销”是公司滥用密码管理器来提取电子邮件地址的常见口号，我们手动分析了攻击代码的脚本，并验证了上述的攻击步骤。

所分析的 100 万个 Alexa 站点中位于前1110个的攻击脚本

Adthink（audienceinsights.net）

Adthink 脚本包含非常详细的个人、财务、身体特征、兴趣和人口统计等信息，包含且不限于出生日期、年龄、性别、国籍、身高、体重、BMI（体重指数）、发色、瞳孔颜色、教育、职业、收入、宠物、住址、贷款、保险、烟草、酒精等等。

OnAudience（behavioralengine.com）

OnAudience 脚本最常出现在波兰的网站，包括报纸、ISP 和在线零售商，OnAudience 脚本的 63 个站点中有 45 个具有 “.pl” 国家/地区代码顶级域。

通过密码管理器读取电子邮件后，OnAudience 脚本会将电子邮件的 MD5 发回服务器，此外脚本还收集浏览器功能，包括插件、MIME 类型、屏幕尺寸、语言、时区信息、用户代理字符串、操作系统和 CPU 信息。

OnAudience 声称只使用匿名数据，但电子邮件地址不是匿名的。如果攻击者想要确定用户是否在数据集中，他们可以对用户的电子邮件地址进行简单地散列，并搜索与该散列关联的记录。

这个攻击并不是最新产生的，类似攻击已经在许多浏览器报告和学术论文中讨论了至少 11 年，以前的讨论大部分都集中在当前功能的安全影响以及自动填充功能的安全可用性权衡上。

研究人员表示，跨站点脚本攻击（XSS）也会从密码管理器中窃取密码，危险性更高，原因有两个：

与 Cookie 盗用相比，XSS 获取的密码可能具有更大的破坏性，因为用户通常在不同的站点重用密码；

由于 XSS 攻击可以在网站内的任何页面上窃取密码，即使是不包含登录表单的密码，登录管理者也可以扩大攻击面的密码盗用。

那为什么 11 年来安全漏洞都没有被解决呢？

网络的安全性取决于同源策略。在系统模型中，不同来源（域或网站）的脚本和内容被视为相互不信任的，并且浏览器保护它们免于相互干扰。但是，如果发布者直接嵌入第三方脚本，而不是将其隔离，则该脚本被视为来自发布者的来源。因此，发布者（及其用户）完全失去了同一起源策略的保护，也就没有任何东西能阻止脚本泄露敏感信息。令人遗憾的是，直接嵌入是常见并且默认的——这也就解释了为什么之前发布的漏洞是合理存在的。

但这种模式并不适合现实情况。发行商不完全信任第三方，因此沙箱隔离和直接嵌入都不合适：一个会限制功能，另一个会带来隐私问题。通过反复研究我们发现，第三方对他们的脚本行为不透明，而且无论如何，大多数发行商并没有时间、也没有这个技术知识来评估行为合理性。因此在可预见的将来，发行商与第三方之间还是会持续陷入这种不安的关系。

浏览器厂商的困境。很明显，同源政策对于今天网络上的信任关系是不适用的，虽然各种安全防御措施会有一定的帮助，但浏览器厂商还是会面临一个两难的问题：他们是否应该防御这个类似的漏洞？或者是否该归咎于嵌入第三方的错？

目前，浏览器供应商多采用嵌入第三方来解决密码管理员的问题，同时也将其视为发布者的责任承担方。但总的来说，仍没有根本性的方法来防御站点上存在的第三方访问导致的敏感数据泄露问题。例如，如果用户同时打开了同一站点的两个选项卡，其中一个包含登录表单，但不包含第三方，则第三方脚本可以“跨越”浏览器选项卡，并且很容易地泄露登录信息。

发布者通过在网站中嵌入第三方，表示完全信任第三方——但是这种情况并不多见，浏览器厂商宁愿选择并不完善的防御措施，例如，引入 HTTPOnly Cookie 属性即是为了通过阻止脚本访问关键 Cookie 来限制 XSS 攻击造成的影响。

还有一个相关的因素：我们发现自动填充不仅仅意味着一个安全漏洞，而且还是一个隐私威胁。尽管安全社区在一般情况下都非常喜欢保守性的解决方案，但是在网络跟踪方面，我们更愿意接受更多的启发式防御措施，例如启用拦截列表。

发布者、用户和浏览器供应商应怎样防止自动填充导致的数据泄露？

发布者通过将登录表单放置在单独的子域中来进行隔离，从而防止自动填写，或者也可以使用像 Safeframe 这样的框架来隔离第三方。虽然这种方法会增加工程复杂性，但借助安全框架，发布者脚本间可以更轻松地进行通信，从而减少了沙盒的影响。不过与简单地将第三方脚本放入网页相比，这些工作还需要发布者额外的工程设计。

用户可以安装广告拦截器或者跟踪保护扩展程序，防止第三方脚本进行跟踪。服务于这个脚本的域（behavioraorangine.com和audienceinsights.net）能被 EasyPrivacy 阻止列表阻止。

对于浏览器供应商，最简单的防御措施是允许用户禁用登录自动填写功能，例如，Firefox 首选项 signon.autofillForms 可以设置为 false 来禁用自动填充凭证。有点技术含量的防御措施是在自动填写登录表单之前要求用户进行交互，但这会给浏览器供应商带来额外的开销。此外也可以增加 W3C Credential Management API，当内置密码管理器自动填充登录信息时，浏览器能够显示相应的通知，当然，这种类型的显示不会直接阻止滥用，但它们会使发布者和注重隐私保护的用户更容易看到潜在的攻击行为。

最后，“writeonly 表单域”也许能够成为一个很有前景的安全登录表单方式，它简要定义了对表单元素的读取访问方法，并建议使用占位符 nonce 来保护自动填充的信息。

写在最后

诚然，内置登录管理器对 Web 安全性有着积极的影响，通过简单地自动密码填充来减少密码重用，并且使得钓鱼攻击更难以安装。然而，根据我们的研究结果，也许浏览器供应商应该重新考虑对自动填写的登录表单进行隐身访问。

更直接地说，对于每个浏览器功能，浏览器开发人员和标准机构都应该考虑如何杜绝滥用不值得信任的第三方脚本。

原文：No boundaries for user identities: Web trackers exploit browser login managers

链接：http://freedom-to-tinker.com/2017/12/27/no-boundaries-for-user-identities-web-trackers-exploit-browser-login-managers/

作者：GUNES ACAR

译者：言则