Closed Bug 1650512 Opened 3 months ago Closed 2 months ago

Sandboxed iframes without allow-storage-access-by-user-activation are incorrectly blocking partitioned storage access

Categories

(Core :: Privacy: Anti-Tracking, defect, P1)

80 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla80
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox77 --- unaffected
firefox78 --- unaffected
firefox79 --- disabled
firefox80 --- fixed

People

(Reporter: andrejsygur, Assigned: xeonchen)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Visit a Classic Google Site that features an HTML Box Gadget. Any site will do as long as it features an HTML Box. Visiting the following test site demonstrates the issue: https://sites.google.com/site/nightlytest163/

Actual results:

The contents of the HTML Box will not be visibly displayed, yet when viewing the source of the page the contents within the HTML Box are still there.

Expected results:

The contents of the HTML Box as per the test site "My First Heading" and "My first paragraph." should be displayed in FireFox Nightly 80.0.1, as they correctly display in Firefox 78.0.1.

Prior screenshot had only Nightly refreshed, this screenshot was taken with both Nightly 80.0.1 and Firefox 78.0.1 refreshed to default no-addon configuration.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

Flags: needinfo?(xeonchen)
Regressed by: 1628486

(In reply to Tom Schuster [:evilpie] from comment #3)

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

The localStorage access is denied [1] by Anti-Tracking because of sandboxing [2] and therefore an exception is raised [3] when clearStorage is called.

If we propagate the reason: *aRejectedReason = blockedReason; in [2], it will get a partitioned localStorage.
But I'm not sure if we didn't do this out of a security reason.

[1] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/StorageAccess.cpp#177
[2] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/ContentBlocking.cpp#985
[3] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/dom/base/nsGlobalWindowInner.cpp#4527

Flags: needinfo?(xeonchen) → needinfo?(amarchesini)

(In reply to Tom Schuster [:evilpie] from comment #3)

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

Thanks, the network.cookie.cookieBehavior fix works.

(In reply to Gary Chen [:xeonchen] from comment #4)

(In reply to Tom Schuster [:evilpie] from comment #3)

Thanks for the reproducible test case. When the site fails clearStorage throws DOMException: The operation is insecure. I tracked this down to Bug 1628486, so this is a Nightly only problem. Setting network.cookie.cookieBehavior to 4 fixes this.

The localStorage access is denied [1] by Anti-Tracking because of sandboxing [2] and therefore an exception is raised [3] when clearStorage is called.

If we propagate the reason: *aRejectedReason = blockedReason; in [2], it will get a partitioned localStorage.
But I'm not sure if we didn't do this out of a security reason.

[1] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/StorageAccess.cpp#177
[2] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/toolkit/components/antitracking/ContentBlocking.cpp#985
[3] https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/dom/base/nsGlobalWindowInner.cpp#4527

Thanks for the investigation Gary! I believe this is a bug. The "Storage Access" sandbox attribute is actually "can this iframe request access to its first-party/unpartitioned cookies (i.e. call the Storage Access API)" and not "can this iframe use storage". Check out the requestStorageAccess docs. See also, the definition of the sandbox flag: https://searchfox.org/mozilla-central/rev/9b282b34b5aa0f836beb735656c55efb2cc4c617/dom/base/nsSandboxFlags.h#114-117.

So we want the iframe to continue to have whatever restrictions are applied to it by default; for things on the blocklist storage access should be denied and for things not on the blocklist partitioned storage should be provided. In neither case should the sandboxed iframe be permitted to requestStorageAccess or have access granted by heuristic, unless the allow-storage-access-by-user-activation flag is set.

Flags: needinfo?(amarchesini) → needinfo?(xeonchen)
Assignee: nobody → xeonchen
Severity: -- → S2
Component: DOM: Core & HTML → Privacy: Anti-Tracking
Priority: -- → P1
Summary: Contents of Classic Google Sites HTML box not being displayed → Sandboxed iframes without allow-storage-access-by-user-activation are incorrectly blocking partitioned storage access

Thanks for investigating, Steven

Flags: needinfo?(xeonchen)
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by xeonchen@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/6b8198545396
propagate rejected reason when storage access is sandboxed; r=timhuang
Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.