Closed Bug 1565373 Opened 5 months ago Closed 5 months ago

Escape from partition by force-creating the initial about:blank document inside a doubly nested tracker iframe

Categories

(Core :: Privacy: Anti-Tracking, task)

task
Not set

Tracking

()

RESOLVED FIXED
mozilla70
Tracking Status
firefox70 --- fixed

People

(Reporter: ehsan, Assigned: ehsan)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

This is similar to bug 1557887, but it happens under a much more subtle set of conditions. Let's say there is the following level of nesting on a web page:

  • Top-level page (1)
    • Tracker iframe (2)
      • Tracker iframe (3)
        • Iframe without a @src (4)

The initial about:blank document has a storage principal which has an empty mFirstPartyDomain in its OA. This goes back to this code which computes the storage principal it inherits from the parent. Inside this function we grab the current document's effective storage principal (that is, frame 3's document), and that leads us to call AntiTrackingCommon::IsFirstPartyStorageAccessGrantedFor() for frame 3's document. However, this function returns the nsIWebProgressListener::STATE_BLOCKED_TRACKER rejection code, since we "fall through" here. That causes us to return the node principal from EffectiveStoragePrincipal() which ultimately means we'll inherit the wrong storage principal...

We shouldn't perform an anti-tracking check here, since that may result
in us picking the node principal unintentionally.

Bugbug thinks this bug is a task, but please change it back in case of error.

Type: defect → task
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5ac4ba7cf676
Use the intrinsic storage principal when inheriting directly; r=baku
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
You need to log in before you can comment on or make changes to this bug.