Service Worker（SW） 是所有现代主流浏览器都支持的强大技术，它可以为web应用提供类似于原生应用的使用体验。但随着Service Worker的流行，它的一些问题也逐渐浮现。在本次分享的论文《Awakening the Web’s Sleeper Agents: Misusing Service Workers for Privacy Leakage》中，在本文中，作者探索了SW的能力和内部工作原理，对 100K 个网站进行采样，对Service Worker API的使用进行了首次全面的大规模研究，并披露了几种嗅探、推断用户隐私的技术。作者已经向相关厂商作了披露，促使 Chromium 团队重新设计站点隔离机制以防御类似的攻击。此外作者还提出了一种保护方法，并开发了其部署工具。
-
Introduction
随着现代浏览器的发展，浏览器已经变成了复杂的应用程序平台，在人们的日常上网活动中发挥着重要作用。为了提供更好的用户体验，浏览器不断引入新功能。而这些新功能往往会带来新的攻击向量。因此安全社区需要深入调查浏览器新功能。而Service Worker这种新技术使Web应用程序可以独立于Web应用程序在后台运行，配合浏览器提供的API，实现了以前Web应用程序无法实现的丰富功能，比如推送通知、后台同步、开发者控制的缓存等。在这篇工作中，作者开发了一个SW的动态分析采样框架，其可以自动访问网站并分析其SW API的使用。作者研究了Alexa排名的前一百万站点，确认其中超过三万的站点正在使用SW。随后，作者实证探索了利用SW可以实现的对用户隐私的嗅探攻击，并确定了几种滥用方式，并发现通过使用 iframe 来激活 SW 可以基本上绕过了浏览器的站点隔离机制。这比以前基于浏览器缓存的攻击更加强大。
2. Background and Threat Model
随着现代主流浏览器的支持，Service Worker填补了传统 Web 应用程序缺少诸如发送推送通知、在后台同步、离线工作和预缓存等功能。SW 独立于 Web 应用程序运行的事件驱动的脚本，它的存在不依赖于 DOM 树。这意味着虽然它们无法操作 DOM 树，但是它们可以在不使用时变为空闲状态，并在下次需要时（例如事件触发时）启动。这个特性使开发人员可以创造可靠、快速且引人入胜的 Web 应用程序的同时，也引入了一些风险。比如通过使用SW的FetchApi，Web应用可以方便对其所使用的网络资源进行缓存。
这不仅可以为应用在无网络环境提供基本的浏览能力，同时可以加快应用在有网络环境下的访问速度。但是，基于SW的缓存和传统的浏览器缓存存在一些区别：首先，SW的缓存是应用主动可编程的，它可以在SW的任何生命周期发生；其次，它不像浏览器缓存那样缓存需要由HTTP标头显示的控制失效时间，一旦SW决定缓存某一个内容，该内容会持续存在直到该SW决定删除它；而且，SW缓存空间可以增长到相当可观的大小（6%~10%可用磁盘空间大小，取决于浏览器实现）。这些区别使得基于SW的缓存攻击比之前基于浏览器缓存的更加有力。而且最近主流浏览器更新了浏览器缓存按站点区分的策略，这使得基于浏览器缓存的攻击几乎失效。
于是，作者沿用了之前先前工作中用于历史嗅探和其他隐私入侵攻击的威胁模型，假设攻击者可以在用户的浏览器中执行JavaScript代码，比如用户访问了一个由攻击者控制的网站。在实践中，可以通过广告等方式扩大威胁规模。
3. methodology and evaluation
首先，作者进行了一个大规模的测量学习，使用爬虫对Alexa排名流行程度前一百万的网站进行了分析，使用selenium驱动一个自行插桩的chromium浏览器收集这些网站使用SW的情况，比如是否使用SW，使用了SW的哪些特性等，触发SW的事件类型和参数等。并得出了如下表的数据。
从表中可以看出SW的使用很广，越流行的网站越有可能使用SW。最受欢迎的SW特性是Web Push和SW对Client的消息，这可能是由于很多Web Push as Service厂商积极使用SW维护长链接。
同时，他们根据对web archive的数据进行分析，发现使用SW的网站由16年7月的24个到20年1月的9k左右，发现SW的使用量仍然在不断上升。
作者提出了一种历史嗅探攻击的方法和设计。简而言之，作者通过判断用户在浏览他们设计的恶意网站时，用户浏览器中出现的 SW 行为判断用户是否有对其他网站的访问历史。当在 SW 中实现了 Fetch 事件处理器之后，源自 SW 范围内的页面的所有 HTTP 请求（即 fetch 事件）都将通过该SW处理。SW 可以通过网络将请求转发到目的地，或者从其缓存存储中返回请求的资源。如下图，
其中 example.com 有一个使用 fetch API 的Web应用。当用户在浏览 example.com 时发出对 example.com/img.jpg 的请求时，该请求将通过 SW 并得到相应处理。当该图片作为跨域资源从 website2.com 请求时，请求不会经过 example.com 的 SW，因为 website2.com 不在 SW 的范围内；而是直接将请求发送到 example.com。但是，如果该 URL 被用作第三方网站（即 website1.com）上 iframe 的来源，则图片请求将通过 SW。换句话说，iframe 触发了 example.com 的 SW，它处理请求的方式与来自第一方网站的请求类似。因此，如果资源被缓存，SW 将从其缓存中返回资源，否则从SW所在网站的服务器获取资源。广泛认为，SW 充当源自其范围内的页面的所有请求的代理。但实际上，由于缺乏适当的隔离，当 iframe 的 src 属性是 SW 范围内的 URL 时，它也可以由第三方网站上的 iframe 触发。这就为历史嗅探攻击创造了一个新的攻击向量。之后恶意网站可以通过SW特有的代码以及资源访问时间判断某一用户是否访问过目标网站。
由于不同浏览器对iframe以及SW的实现方式不同，这两种判断方式可能会有一些差异。比如在使用SW的PerformanceAPI的时候，如果iframe网站使用安全标头组织iframe展示，Chromium会获取资源但是在接口中不返回内容，而Firefox获取资源的同时会响应NHP接口从而导致攻击成功。而Safari对每一个iframe都统一重新执行SW的安装，所以无法进行任何嗅探。
而对于 SW 嗅探的危害，作者发现其通过嗅探资源的存在性，可以进一步发现用户是否浏览过某个页面（比如通过链接某个eshop商品）、用户是否登录过某个网站（比如通过检查某个登录后特有的资源），甚至是用户所加入的WhatsApp群组。如果有针对性地利用，攻击者有可能对受害者实施去匿名化的攻击。而随着 SW 在 Web 开发社区中的持续吸引力，它对用户构成的威胁只会随着时间的推移而增加。因此，作者向所有易受攻击的浏览器开发商和 Web 服务披露了调查结果。
以上，谢谢大家阅读。篇幅有限，欢迎移步原文查看算法详情以及代码列表。
原文始发于微信公众号（COMPASS Lab）：论文分享｜Misusing Service Workers for Privacy Leakage
