Re: [w3c/ServiceWorker] Support No-Vary-Search header in Cache API (Issue #1798)

ricea left a comment (w3c/ServiceWorker#1798)

> The cache API is also partitioned. Does this not mitigate it like in the http cache case?

On second thought, maybe cache partitioning doesn't mitigate this. An attacker can perform a timing attack with "no-cors" fetch to determine whether or not an item is cached. The thing that's saving us in practice is that most of these login-guarded resources cannot be served fresh from cache, and cannot be revalidated. so the attacker has to determine the difference between "there was a cache entry but it couldn't be used" and "there was no cache entry" but those two times only differ by microseconds at most.

On the other hand, the Cache API doesn't care about staleness, so asking the question "is there a cache entry for this" is easy and 100% reliable.

To sketch an attack, the malicious page does:
```
await cache.add("https://target/protected/page?ignoredname=1");
if (await cache.match("https://target/protected/page?ignoredname=2")) {
  userIsLoggedInToTarget = true;
}
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1798#issuecomment-3468185973
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1798/3468185973@github.com>