Closed Bug 1685355 Opened 9 months ago Closed 9 months ago

Clear-site-data header does not clear partitioned storage

Categories

(Core :: Storage: StorageManager, defect)

defect

Tracking

()

RESOLVED FIXED
86 Branch
Tracking Status
firefox86 --- fixed

People

(Reporter: pbz, Assigned: pbz)

References

(Depends on 1 open bug, Blocks 2 open bugs)

Details

Attachments

(1 file)

We currently use a regular principal to clear storage when cross origin 3rd parties send the "Clear-Site-Data" header. This leads to clearing the non partitioned storage and makes it unable for the 3rd party to clear its partitioned storage.
Changing the DeleteDataFromPrincipal call here to use the storage principal should fix this: https://searchfox.org/mozilla-central/rev/a0ccd492719b1ad2106f6456549be62a76f45acb/toolkit/components/clearsitedata/ClearSiteData.cpp#161,212

See https://bugzilla.mozilla.org/show_bug.cgi?id=1626724#c2 for discussion.

Status: NEW → ASSIGNED
Pushed by pzuhlcke@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/dc0d1d98e111
Use storage principal when clearing data via clear-site-data header. r=johannh
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Status: RESOLVED → REOPENED
Flags: needinfo?(pbz)
Resolution: FIXED → ---
Target Milestone: 86 Branch → ---

This crashed for sandboxed sites, because we called GetIsOriginPotentiallyTrustworthy on a nullptr:
https://searchfox.org/mozilla-central/rev/dac45cc7020dfddbcc937827810dd11550c07dc3/toolkit/components/clearsitedata/ClearSiteData.cpp#166

We get the principal here: https://searchfox.org/mozilla-central/rev/dac45cc7020dfddbcc937827810dd11550c07dc3/toolkit/components/clearsitedata/ClearSiteData.cpp#161

Without the patch we use the document principal, which is a NullPrincipal for the sandbox case:
https://searchfox.org/mozilla-central/rev/dac45cc7020dfddbcc937827810dd11550c07dc3/caps/nsScriptSecurityManager.cpp#303-309

With the patch we use GetChannelResultStoragePrincipal, which calls StoragePrincipalHelper::Create. For the sandboxed case it will get a NullPrincipal so the clone call here will return a nullptr:
https://searchfox.org/mozilla-central/rev/dac45cc7020dfddbcc937827810dd11550c07dc3/toolkit/components/antitracking/StoragePrincipalHelper.cpp#109-110

I’ve updated the patch to perform a null check. This doesn’t change behavior, we already drop calls where the document principal is a NullPrincipal via the GetIsOriginPotentiallyTrustworthy check.

Flags: needinfo?(pbz)

Yeah I guess that is https://github.com/w3c/webappsec-clear-site-data/issues/64?

Anne, in the meantime to do you have any recommendation what we should do about opaque origins? (In a follow-up?)

Flags: needinfo?(annevk)

Opaque origins shouldn't be able to have storage or cookies so that should no-op, I think. If we do something different (which seems unlikely) I recommend leaving a comment in that issue so it gets considered when it is finally defined.

Flags: needinfo?(annevk)
Pushed by pzuhlcke@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3df455e2d5a8
Use storage principal when clearing data via clear-site-data header. r=johannh
Status: REOPENED → RESOLVED
Closed: 9 months ago9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Depends on: 1688665
Blocks: 1726038
You need to log in before you can comment on or make changes to this bug.