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

Issue 798672 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

queryUsageAndQuota allows to get size of no-cors request

Reported by psuw...@atlassian.com, Jan 3 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce the problem:
1. create worker and in it
 a. execute no-cors fetch
 b. put request and response in cache
2. execute navigator.webkitTemporaryStorage.queryUsageAndQuota in browser 

What is the expected behavior?
pages with no-cache headers shouldn't be allowed to get cached.

OR

navigator.webkitTemporaryStorage.queryUsageAndQuota shouldn't return precise values.

What went wrong?
`queryUsageAndQuota` returns the size of cache.
If we try to send no-cors request to login page it will try to login.

Fetch request won't return any useable data, but if we cache the request then usageQuota will be updated by the size of request and response.

If we compare sizes of consequential request then it may be possible to differentiate request which succeeded from these that didn't solely relying on occupied size of cache.

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 63.0.3239.84  Channel: stable
OS Version: OS X 10.13.2
Flash Version:
 
Labels: Needs-Triage-M63
Cc: krajshree@chromium.org
Labels: Needs-Feedback Triaged-ET
psuwala@ - Thanks for filing the issue...!!

Could you please provide a sample url/test file to test the issue from TE-end. This will help us in triaging the issue further.

Thanks...!! 
Components: Blink>Storage>Quota Blink>SecurityFeature>CORS
Cc: jkarlin@chromium.org cmumford@chromium.org
To mitigate this issue we should be padding the size of opaque responses as seen by the quota system. This padding was enabled in 63.

Do you have a repro that demonstrates this in 63?

(Also, is there really anything Worker specific about the steps?)

I will try to deliver poc it this week.

When was 63 released?
Can non worker access cache or usageQuota?
Project Member

Comment 6 by sheriffbot@chromium.org, Jan 7 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
queryUsageAndQuota will return a size, but it should have a randomized amount of padding on it. So you shouldn't be able to determine cached vs non-cached very easily. At least not more easily than you could by other means (such as network timing of the resource load).
I was testing the bug one month ago.
It seems that 63 was released around this time.
I will reassess. 
Re: "Can non worker access cache or usageQuota?"

Yes. Any secure context (roughly: page/worker served by https or localhost) can access `self.caches` and can call `navigator.storage.estimate()`

(The legacy quota APIs return the same values.)
Components: -Blink>Workers
-Workers per comment 9.
Cc: -jkarlin@chromium.org mkwst@chromium.org
Owner: jkarlin@chromium.org
Status: Assigned (was: Unconfirmed)
Josh: I'm just going to assign this to you. If it turns out that the padding y'all introduced mitigates this report, please close it out. :)
Hello,

padding fixed the issue.

Thank you for support and keeping us safe,
Peter.
Status: WontFix (was: Assigned)
Our pleasure! Thanks for the report.

Sign in to add a comment