New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 596927 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 548556
Owner:
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Blocked on:
issue 548556



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.
 
quota-api-example.html
875 bytes View Download

Comment 1 by wfh@chromium.org, Mar 22 2016

Cc: jww@chromium.org mkwst@chromium.org
Components: Blink>SecurityFeature
Labels: -OS-Mac OS-All
mkwst, jww can you triage this report?

Comment 2 by wfh@chromium.org, Mar 23 2016

Cc: kinuko@chromium.org horo@chromium.org
Owner: nhiroki@chromium.org
nhiroki you appear to be an owner of this code, can you take a look at this security report?
Components: Blink>Storage>CacheStorage Blink>Storage>Quota
Mergedinto: 548556
Status: Duplicate (was: Unconfirmed)
Cc: falken@chromium.org

Comment 5 by wfh@chromium.org, 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.
Blockedon: 548556
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?
Any update?
Labels: allpublic
Project Member

Comment 10 by sheriffbot@chromium.org, Feb 24 2018

Labels: -Restrict-View-SecurityTeam
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