
最近,已经彻底公开了两个使用隐藏的登录表单来收集登录信息的Web跟踪服务,即Adthink()和OnAudience(). 本文将介绍第三方脚本如何在没有用户授权的情况下使用浏览器的内置登录管理器(也称为密码管理器)来检索和公开用户信息.

事实上,密码管理器的潜在漏洞早已为人所知. 过去,漏洞主要是由于跨站点恶意脚本(XSS)攻击引起的密码泄漏. 但是,在分析了50,000个网站之后,我们没有发现密码被盗. 相反,我们发现跟踪脚本被滥用,导致大量用于构造跟踪标识符的电子邮件地址.

上图显示了此过程: 首先,用户在页面上填写登录表单,并要求浏览器保存登录信息(跟踪脚本未显示在登录页面上). 然后,用户访问同一网站上包含第三方跟踪脚本的另一个页面. 跟踪脚本将自动插入一个不可见的登录表单,该表单由密码管理器自动填写. 第三方脚本通过阅读填写的表单来检索用户的电子邮件地址,并将该电子邮件地址发送给第三方服务器.
所有主流浏览器均具有内置的登录管理器,该管理器可以自动保存并自动填写用户名和密码数据,从而使登录体验更加流畅. 因此,无论表单是否可见,登录表单都会自动填写,并且通常不需要用户交互. 在我们的测试中,除非用户单击或触摸页面,否则Chrome不会自动填写密码字段. 因此,对于保存在密码管理器中的用户名(通常是电子邮件地址)和密码,第三方脚本可以创建一个表格并自动填写.
为什么要收集电子邮件地址?一方面,因为电子邮件地址是唯一的,所以它是一个很好的跟踪标识符. 另一方面,用户的电子邮件地址几乎不会更改,使用私人浏览模式或切换设备清除Cookie不会阻止跟踪. 此外,电子邮件地址可用于连接移动应用程序中的设备和配置文件,还可用作cookie清除前后浏览历史记录配置文件之间的链接.
通过密码管理器获取用户信息

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

在分析的100万个Alexa站点中,排名前1,110的攻击脚本
Adthink()
注入Adthink脚本后,它将自动通过不可见的形式读取电子邮件地址,然后将电子邮件地址的MD5,SHA1和SHA256发送到其服务器(),然后Adthink将触发另一个包含通过电子邮件将请求发送给数据代理Acxiom().
Adthink脚本包含非常详细的个人,财务,身体特征,兴趣和人口统计信息,包括但不限于出生日期,年龄,性别,国籍,身高,体重,BMI(体重指数),头发颜色,学生的肤色,教育程度,职业,收入,宠物,地址,贷款,保险,烟草,酒精等.
OnAudience()
OnAudience脚本最常出现在波兰的网站上,包括报纸,ISP和零售商. OnAudience脚本中的63个站点中,有45个具有“ .pl”国家/地区代码顶级域.
通过密码管理器读取电子邮件后,OnAudience脚本会将电子邮件的MD5发送回服务器. 此外,该脚本还收集浏览器功能,包括插件,MIME类型,屏幕大小,语言,时区信息,用户代理字符字符串,操作系统和CPU信息.
OnAudience声称仅使用匿名数据,但电子邮件地址不是匿名数据. 如果攻击者想确定用户是否在数据集中,他们可以简单地对用户的电子邮件地址进行哈希处理并搜索与哈希相关的记录.

这不是最新的攻击. 至少11年以来,许多浏览器报告和学术论文中都讨论了类似的攻击. 先前的大多数讨论都集中在当前功能的安全影响以及自动填充功能的安全可用性折衷上.
研究人员说,跨站点脚本(XSS)攻击也可以从密码管理器中窃取密码,这更危险,原因有两个:
与Cookie盗用相比,XSS获得的密码可能更具破坏性,因为用户通常在不同的站点上重复使用密码;
由于XSS攻击可以窃取网站上任何页面上的密码,即使该密码不包含登录表单,登录管理员也可以扩大攻击范围以盗窃密码.
那为什么11年没有解决安全漏洞?

网络的安全性取决于同源策略. 在系统模型中,来自不同来源(域或网站)的脚本和内容被认为是相互不信任的,浏览器可以保护它们免受相互干扰. 但是,如果发布者直接嵌入第三方脚本而不是隔离它,则该脚本被视为来自发布者的来源. 因此,发布者(及其用户)完全失去了对同一原始策略的保护,并且没有什么可以阻止脚本泄漏敏感信息. 遗憾的是,直接嵌入是常见的,并且是默认嵌入的,它默认解释了为什么以前发布的漏洞合理.
但是这种模型不适合现实. 发布者并不完全信任第三方,因此沙盒隔离或直接嵌入都不合适: 一个限制功能,另一个限制隐私. 通过反复研究,我们发现第三方对其脚本行为并不透明,无论如何,大多数发布者都没有时间或技术知识来评估其行为的合理性. 因此,在可预见的将来,出版商和第三方将继续陷入这种不安的关系.
浏览器供应商的困境. 显然,同源策略不适用于当今Internet上的信任关系. 尽管各种安全防御措施将在一定程度上有所帮助,但浏览器供应商仍面临两难境地: 他们是否应防御此类似漏洞?还是应该归咎于嵌入式第三方的过失?
当前,浏览器供应商大多使用嵌入式第三方来解决密码管理器的问题,并将其视为发布者的责任. 但是总的来说,仍然没有基本的方法来防止由于站点上的第三方访问而导致敏感数据泄漏. 例如,如果用户同时打开同一站点的两个选项卡,其中一个包含登录表单,但不包含第三方,则第三方脚本可以“跨越”浏览器选项卡并轻松显示登录信息.
发布者通过将第三方嵌入其网站来表达对第三方的完全信任,但这并不常见. 浏览器供应商宁愿选择不完善的防御措施. 例如,引入HTTPOnly Cookie属性可通过阻止脚本访问关键Cookie来限制XSS攻击的影响.
还有一个相关因素: 我们发现自动填充不仅意味着安全漏洞,而且还意味着隐私威胁. 尽管安全社区通常喜欢保守的解决方案,但就网络跟踪而言,我们更愿意接受更多启发式防御措施,例如启用阻止列表.
发布者,用户和浏览器供应商应如何防止由于自动填充导致的数据泄漏?
发布者可以通过将登录表单放在单独的子域中来隔离登录表单,以防止自动填充,也可以使用Safeframe之类的框架来隔离第三方. 尽管此方法会增加工程复杂性,但是借助安全框架,发布者脚本可以更轻松地进行通信,从而减少沙盒的影响. 但是,与简单地将第三方脚本放入网页相比,这些任务需要发布者进行其他工程设计.

用户可以安装广告或跟踪保护扩展,以防止跟踪第三方脚本. EasyPrivacy阻止列表可以阻止提供此脚本的域(和).
对于浏览器供应商,最简单的防御措施是允许用户禁用自动登录功能. 例如,可以将Firefox首选项signon.autofillForms设置为false以禁用自动填充凭据. 一种技术上的防御是要求用户在自动填写登录表单之前进行交互,但这会给浏览器供应商带来额外的开销. 另外,可以添加W3C凭据管理API. 当内置的密码管理器自动填写登录信息时,浏览器可以显示相应的通知. 当然,这种类型的显示并不能直接防止滥用,但它们会使发布者和关注隐私受到保护的用户更有可能看到潜在的攻击. </ p>
最后,“只写表单域”可能成为有希望的安全登录表单方法. 它简要定义了表单元素的读取访问方法,建议使用占位符随机数来保护自动填充的信息.
写在最后
确实,内置的登录管理器会对Web安全产生积极影响,只需简单地自动自动填充即可减少密码重用,并使网络钓鱼攻击更难以安装. 但是,根据我们的研究结果,也许浏览器供应商应该重新考虑对自动填写的登录表单的隐身访问.
更直接地说,对于每种浏览器功能,浏览器开发人员和标准机构应考虑如何防止滥用不受信任的第三方脚本.
原始信息: 用户身份无边界: Web跟踪器利用浏览器登录管理器
作者: GUNES ACAR
翻译者: 语言规则
原始信息: 用户身份无边界: Web跟踪器利用浏览器登录管理器
作者: GUNES ACAR
翻译者: 语言规则
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/shumachanpin/article-309674-1.html
本来看着修复的是6s的功能傲娇的不想升级哦哦哦哦哦这个表情把我看酥了升升升升