苹果公司解决 WebKit 框架中的 HSTS 用户跟踪问题

苹果公司为 WebKit 框架添加了新的保护措施,以防止可能滥用 HTTP 严格传输安全(HSTS)安全标准来跟踪用户。HSTS 提供了一种机制,通过这种机制,网站只能通过安全连接和直接浏览器访问安全版本所在的位置来声明自己。 基本上,当用户尝试连接到网站的不安全版本时,HSTS 强制浏览器转到网站的 HTTPS 版本。

苹果公司解决 WebKit 框架中的 HSTS 用户跟踪问题

由于 HSTS 告诉网络浏览器在被重定向到安全位置时记住并且将来自动去那里,可以创建一个“超级 cookie”,并且它可以被跨站点跟踪器读取。攻击者可以利用用户的  HSTS 缓存在设备上存储一位信息。 通过注册大量域并强制从受控子域中加载资源,攻击者“可以创建足够大的比特向量来唯一地表示每个站点访问者。”

在 HSTS 规范中描述了这个问题:“对于那些控制一个或多个 HSTS 主机的人来说,将信息编码成他们控制的域名是可能的,并且使得这些 UA 缓存这些信息当然是在注意 HSTS 的过程中 主办。 这些信息可以由其他主机通过巧妙构建和加载的网络资源来检索,导致 UA 发送查询到(变体)编码的域名。“

缓解这种跟踪攻击并不容易,因为它需要平衡安全和隐私目标。 但是,由于 HSTS 的隐私风险仅作为理论追踪向量呈现,但尚未提供实际恶意滥用协议的证据,因此浏览器将遵守网站提供的所有 HSTS 指令。

苹果最近意识到这种理论攻击已经开始针对 Safari 用户进行部署。 这促使这家科技巨头开创了一个既保护安全网络流量又减少跟踪的解决方案。由于 HSTS 漏洞需要创建一个初始跟踪标识符并读取它,苹果建议对攻击双方进行缓解。

一方面,苹果公司修改了网络堆栈,只允许为加载的主机名或顶级域 + 1 设置 HSTS 状态。因此,跟踪器不能再有效地在大量不同的位上设置 HSTS,但需要单独 访问跟踪标识符中具有活动位的每个域。 WebKit 还限制了可以链接在一起的重定向数量,从而限制了可以设置的位数。另一方面,当动态 HSTS 导致一个不安全的第三方子资源从被阻塞的 cookie 升级到认证连接的域中加载时,苹果还修改了 WebKit 以忽略 HSTS 升级请求(并使用原始 URL)。

在内部回归测试,公共种子和最终的公共软件发布期间收集的遥测数据表明,上述两种缓解成功地阻止了 HSTS 超级 cookie 的创建和阅读,同时又不会使第一方内容的安全目标退步。 我们相信他们符合最佳实践,并保持 HSTS 提供的重要安全保护。

稿源:东方安全,封面源自网络;

苹果公司解决 WebKit 框架中的 HSTS 用户跟踪问题

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论