Cromite项目中Blink内存缓存的安全隐患分析

在Chromium分支项目Cromite的最新版本v130中，开发者发现了一个与Blink渲染引擎内存缓存相关的潜在安全问题。这个问题最初是通过privacytests.org的缓存测试失败而被发现的，经过深入分析，发现这涉及到浏览器缓存机制的底层实现细节。

问题背景

Blink渲染引擎维护了一个内存缓存机制，主要用于处理data URL请求，避免这些请求需要通过mojo调用网络栈。然而在实际调试中发现，这个缓存机制也被应用于其他资源类型，特别是图片资源。与HTTP缓存不同，Blink的内存缓存采用了不同的逻辑，最初的分区补丁(Partition-Blink-memory-cache.patch)未能完全正确地处理这种情况。

技术细节

Blink的内存缓存存在几个关键特性：

1. 进程级别共享：内存缓存是以进程为单位进行共享的，这意味着同一进程内的不同站点可以访问相同的缓存资源。

2. 标识符问题：缓存标识仅基于URL，没有进行适当的分区处理。在补丁实现中，原本应该使用top-frame-url进行分区，但实际上却使用了frame initiation url，这导致了分区失败。

3. 隐私风险：由于缓存共享机制，攻击者可能通过时序攻击探测缓存中是否存在特定资源，从而获取跨站信息。

问题影响

在Cromite项目中，这个问题表现为：

• 即使启用了严格的站点隔离(SitePerProcess)和OOPIF(Out-of-Process iframes)保护，内存缓存仍可能导致跨站信息泄露。

• 对于data URL的处理，虽然理论上可以通过base64宽容解码来交换跨站数据，但实际风险较低。

• 在privacytests.org的测试中，privacytests.org和privacytests2.org这两个理论上应该隔离的站点却共享了缓存资源。

解决方案

经过深入分析，开发者确定了问题的根本原因：

1. Worker环境下的top-origin-url缺失：在Service Worker环境中，top-origin-url没有被正确设置，导致缓存标识符使用了不正确的initiator url。

2. 缓存控制权问题：缓存标识符的选择权应该由浏览器层面控制，而不是由Blink引擎自行决定。

基于这些发现，项目决定：

• 完全禁用Service Worker环境下的内存缓存使用
• 确保所有缓存操作都经过浏览器层面的安全控制
• 避免在Blink层面自行决定缓存策略

结论

这个案例展示了浏览器缓存机制的复杂性，特别是在多进程架构下的安全边界维护。即使是看似简单的内存缓存机制，也可能成为隐私保护的薄弱环节。Cromite项目通过禁用有风险的内存缓存功能，确保了更严格的跨站隔离，为用户提供了更强的隐私保护。这也提醒我们，在浏览器安全设计中，缓存机制必须与进程隔离、站点隔离等安全措施协同工作，才能提供全面的保护。