Issue metadata
Sign in to add a comment
|
Quota Management API exposes size of cross-origin resources
Reported by
tomvango...@gmail.com,
Mar 22 2016
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
Steps to reproduce the problem:
1. Request current quota:
navigator.webkitTemporaryStorage.queryUsageAndQuota(function(quota, usage) {
console.log(quota)
});
2. Store remote resource using the Cache API:
fetch('https://example.org/resource', {mode: "no-cors", credentials: "same-origin"}).then(function(resp) {
cache.put(new Request('foo'), resp.clone());
});
3. Request quota again. Subtract quota from (1). The result will be the exact size of the remote resource.
What is the expected behavior?
The size of opaque Responses should remain hidden.
What went wrong?
It is trivial to expose the size of any remote resource, even from authenticated requests. Since the size of many endpoints is related to the state of the user at that website, this attack allows adversaries to infer private information as long as JavaScript can be executed in *any* context.
If it helps, I can provide several real-world examples of such attack scenarios.
Did this work before? N/A
Chrome version: 49.0.2623.87 Channel: stable
OS Version: OS X 10.9.5
Flash Version: Shockwave Flash 21.0 r0
The Quota Management API is flawed by design when considering any Response (including opaque ones) can be added to the Cache.
,
Mar 23 2016
nhiroki you appear to be an owner of this code, can you take a look at this security report?
,
Mar 24 2016
,
Mar 24 2016
,
Mar 24 2016
Hi, thanks for your report. We are discussing this issue internally and will update this bug once we know what our plans are.
,
Mar 24 2016
,
Mar 24 2016
Thanks. From what I understand, the Storage standard (https://storage.spec.whatwg.org) aims to provide similar functionality (i.e. https://storage.spec.whatwg.org/#dom-storagemanager-estimate). Are the plans to replace the Quota Management API for this Storage standard, just keep the Quota Management API, or adopt both? In either case, both these APIs suffer from similar issues, which should be fixed at the spec level as these are design flaws rather than implementation bugs. But depending on the plans, either the Quota Management API (only adopted by Chrome), or the Storage standard (not adopted yet), or both should change. There are some similar issues with CacheStorage that lead to knowing the exact size of cross-origin resources (e.g. by abusing the fixed quota per domain, and checking when QuotaExceededError fires). Should I report these here, or in separate issues?
,
Jun 25 2016
Any update?
,
Oct 2 2016
,
Feb 24 2018
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by wfh@chromium.org
, Mar 22 2016Components: Blink>SecurityFeature
Labels: -OS-Mac OS-All