引言:从离线存储到侧信道探针
Origin Private File System(OPFS)是浏览器为支持现代 Web 应用而设计的本地存储接口,旨在为照片编辑器、IDE、游戏等应用提供高性能的私有文件系统访问能力。与传统 File System Access API 不同,OPFS 无需用户通过文件选择器授权,即可在浏览器沙箱内创建和操作文件,这使其成为 Progressive Web App 实现离线功能的关键基础设施。
然而,Graz University of Technology 的研究团队近期发表的 FROST(Fingerprinting Remotely using OPFS-based SSD Timing)研究揭示了这一设计的安全盲区:OPFS 的高性能特性使其能够作为精确的时序测量探针,通过监测 SSD 访问延迟的变化,远程推断用户正在访问的其他网站或运行的本地应用程序。
技术机制:共享存储资源的时序侧信道
FROST 攻击的核心在于利用 SSD 作为共享硬件资源的物理特性。现代 SSD 控制器内部包含队列、闪存转换层、缓存和调度算法,当多个进程同时发起 I/O 请求时,会产生资源争用,导致访问延迟的微小波动。
攻击者通过 JavaScript 在 OPFS 中创建一个大于系统内存的文件(通常数 GB),然后执行高频率的随机 4KB 读取操作。选择随机读取而非顺序读取的目的是绕过操作系统页缓存的预取机制,确保每次读取都实际触及 SSD 硬件。通过 performance.now() 等高精度计时 API 测量每次读取的延迟,攻击者可以构建一条时序轨迹。
当用户在其他标签页访问特定网站或启动本地应用时,这些操作会产生特征性的存储 I/O 模式。例如,加载一个复杂的 Web 应用可能涉及缓存资源的读取、浏览器状态写入、媒体资源加载等操作。这些 I/O 活动与攻击者的 OPFS 读取产生 SSD 争用,在时序轨迹上留下可识别的 "签名"。
研究的关键突破在于解决了此前 SSD 侧信道研究的一个核心限制:先前的工作依赖 io_uring 等原生内核 API 实现高精度时序测量,需要本地代码执行。FROST 证明,通过精心设计的 OPFS 访问模式和足够大的文件,完全可以在浏览器沙箱内实现同等精度的测量,无需任何用户交互或权限提示。
攻击能力量化:从网站指纹到隐蔽信道
研究团队在受控环境中对 FROST 进行了系统评估,结果展示了该技术的实际威胁程度。
网站指纹识别:在闭世界场景(假设用户只访问 50 个已知网站之一)中,针对 macOS 系统的 Top-50 网站指纹识别达到了 88.95% 的 F1 分数。在开世界场景(用户可能访问任意网站)中,宏平均 F1 分数仍达到 86.95%。这意味着攻击者能够以较高准确率识别用户正在浏览的特定网站。
应用指纹识别:对于本地应用程序(如 Contacts、Music、Keynote、System Settings 等 macOS 应用),闭世界场景下的 F1 分数高达 95.83%。应用启动时读取库文件、配置文件和资源文件的 I/O 模式具有高度可识别性。
隐蔽信道容量:研究还构建了从本地应用到恶意网页的数据泄露信道,在 Linux 系统上实现了 661.63 bit/s 的真实信道容量,在 macOS 上达到 891.77 bit/s。这一速率足以在合理时间内传输敏感信息,如加密密钥片段或身份标识符。
这些数字需要放在具体语境中理解:它们来自特定硬件配置和受控实验环境,实际攻击效果会因 SSD 型号、固件版本、操作系统缓存策略、浏览器行为以及用户工作负载而有所差异。然而,研究结果明确表明,浏览器可访问的 SSD 时序信息包含了足以支持实用分类的信号强度。
防御困境:厂商响应与缓解策略的局限
FROST 研究团队已向 Google、Apple 和 Mozilla 负责任地披露了研究发现。各厂商的回应揭示了当前浏览器安全模型在处理侧信道威胁时的结构性挑战。
Chromium 安全团队明确表示不将指纹识别攻击视为安全漏洞,这意味着该问题不会通过常规安全更新渠道获得紧急修复。Apple 认为攻击超出当前安全范围,但保留未来实施缓解措施的可能性。Mozilla 已确认研究结果,但在论文发表时尚未实施具体缓解方案。
这种响应差异反映了浏览器厂商在功能性与隐私保护之间的权衡困境。OPFS 的零权限设计是其核心卖点 —— 如果为每次 OPFS 使用添加权限提示,将严重损害依赖该 API 的离线优先 Web 应用的用户体验。添加随机延迟或降低计时精度可能缓解攻击,但也会伤害合法的性能分析、游戏和媒体应用。
更深层的挑战在于,传统的同源策略和进程隔离无法阻止此类攻击。FROST 攻击者从未尝试读取其他来源的数据,而是测量自身操作在共享硬件上产生的时序副作用。进程隔离可以阻止跨进程内存访问,但无法使 SSD 对每个来源保持独立。
工程化防御建议:可落地的参数与清单
尽管浏览器层面的全面缓解仍需时间,开发者和企业安全团队可以采取以下措施降低暴露风险。
开发者层面的脚本治理
Content Security Policy (CSP) 配置:
Content-Security-Policy: script-src 'self' https://trusted-cdn.example.com;
object-src 'none';
base-uri 'self'
严格限制脚本来源,减少第三方代码执行指纹采集的机会。
第三方脚本审计清单:
- 识别所有加载的第三方脚本(分析、广告、客服、A/B 测试等)
- 评估每个脚本是否必须使用 OPFS、高分辨率计时器、WebAssembly 等高风险 API
- 对非必要脚本实施延迟加载或移除
- 使用 Subresource Integrity (SRI) 固定关键静态脚本
敏感页面隔离:对于银行、医疗、企业门户等高风险页面,避免嵌入任何第三方脚本。将分析功能移至服务器端实现,减少客户端代码暴露面。
企业安全策略
浏览器策略配置(针对 Chromium 企业版):
- 监控并限制
performance.now()的可用性 - 对敏感用户组启用站点隔离增强模式
- 考虑在端点检测与响应 (EDR) 系统中添加对异常 OPFS 访问模式的检测规则
用户行为建议:
- 避免在访问敏感服务时保持不信任标签页打开
- 为银行、工作通信等敏感任务使用独立的浏览器配置文件或专用浏览器
- 定期清理站点数据(包括 OPFS 存储)
- 考虑使用具有指纹防护功能的隐私浏览器(如 Brave、Firefox 的增强追踪保护模式)
潜在的技术缓解方向
浏览器厂商可能考虑的缓解措施包括:
- 分层权限模型:小容量 OPFS 使用保持无提示,大文件分配或高频随机读取触发用户激活要求
- 时序抖动:对 OPFS 操作添加可控的随机延迟,降低测量精度而不显著影响用户体验
- 后台节流:对隐藏标签页或后台页面的 OPFS 访问实施更严格的速率限制
- 启发式检测:识别符合测量特征的行为模式(大文件 + 高频随机读取 + 持续计时调用)并自动降级计时精度
结论
FROST 攻击揭示了现代 Web 平台的一个根本性张力:浏览器越接近原生应用的能力,就越容易继承原生环境的侧信道风险。OPFS 作为支持本地优先 Web 应用的关键基础设施,其高性能特性意外地为远程攻击者提供了硬件级时序测量能力。
这一发现的意义超越了 SSD 时序本身。它表明,任何提供高性能本地访问的 Web API 都可能成为侧信道端点 —— 无论是 GPU、NPU、硬件视频解码器还是本地 AI 模型缓存。浏览器安全模型需要从 "阻止直接访问" 演进为 "管理间接测量",在保持 Web 平台竞争力的同时,为用户提供对硬件行为的合理隐私预期。
对于当前的用户和开发者而言,务实的防御策略是实施脚本治理、分离敏感会话,并关注浏览器厂商对 OPFS 计时行为的后续调整。FROST 并非浏览器沙箱的崩溃,而是提醒我们:沙箱可以阻止代码进入隔壁房间,但无法阻止它听到墙壁另一侧的声音。
参考来源
- Weissteiner, H., et al. "FROST: Fingerprinting Remotely using OPFS-based SSD Timing." DIMVA 2026. https://hannesweissteiner.com/pdfs/frost.pdf
- "The browser feature that turns SSD timing into a tracking signal." Webiano Digital, 2026. https://webiano.digital/the-browser-feature-that-turns-ssd-timing-into-a-tracking-signal/
- "Websites have a new way to spy on visitors: analyzing their SSD activity." Ars Technica, 2026.
- "Origin private file system." MDN Web Docs. https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Origin_private_file_system
内容声明:本文无广告投放、无付费植入。
如有事实性问题,欢迎发送勘误至 i@hotdrydog.com。