1647681 - Circumventing anti-tracking with top-level sandboxing

Status: VERIFIED FIXED

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

Description

[Johann Hofmann [:johannh]]

tl;dr I believe that using CSP: sandbox on the top-level document almost all current anti-tracking measures such as content blocking and cookie restrictions can be circumvented.

POC is here: https://sandboxed-with-trackers.glitch.me/

Top-level sandboxed pages are pages that are sending the Content-Security-Policy: sandbox; header as part of their HTTP response headers. This will put them in a similar state as iframes with the sandbox attribute, they get a null principal and are generally not same-origin with what's shown in the URL bar.

I initially noticed that these pages are not getting any shield icon in the url bar, which makes total sense considering that they can't receive tracking exceptions on their principal, but that is probably also a separate bug.

This top-level null principal seems to have further deep implications on our anti-tracking measures, as no tracking or fingerprinting resources loaded from top-level sandboxed documents will be blocked, and cookie restrictions from ETP also do not seem to apply regularly.

Of course sandboxed documents operate under restricted conditions, and they can't access their same-origin storage and cookies. This extends to their embedded iframes, but unfortunately it does not apply when loading resources such as images or iframes with SameSite=None cookies. Thus, a possible attack could look like this:

• news.com wants to enable several online trackers to show more "relevant" advertisement based on cross-site tracking.
• news.com sandboxes all its top-level pages except those where user account data is needed, i.e. the free version of the site is sandboxed and the behind-paywall version is not sandboxed
• news.com loads tracker.com and fingerprinter.com successfully, bypassing any content blocking
• To circumvent standard ETP cookie restrictions, tracker.com loads iframe ads that only rely on the HTTP cookie header for identifying the user and pass this state on via query params etc.

From my testing dFPI doesn't seem to help with this, purging is obviously unaffected and does help close this avenue a little.

(see POC)

Comment 1

[Johann Hofmann [:johannh]]

news.com sandboxes all its top-level pages except those where user account data is needed

Thinking more about this, if they don't rely on document.cookie on the client they can just sandbox literally all their content except the login page.

Comment 2

[Ethan Tseng [:ethan]]

Dimi, the solution might be related to URL Classifier. Could you take a look to see if you can take over this bug?
Talk to Johann or Baku if you have any questions.

Comment 3

[Dimi Lee [:dimi]]

Coincidentally, I am working on another Bug 1437626 and one of the patches fixes this issue.
But note that the patch doesn't fix not showing shield icon in the url bar. As johnn mentioned, that should be a separate bug.

Comment 4

[Dimi Lee [:dimi]]

This issue should be fixed by the patch in Bug 1437626. I'll write a testcase for this.

Comment 5

[Dimi Lee [:dimi]]

Attachment: Bug 1647681 - Add a testcase to ensure channels with top-level sandboxing are classified r=baku

Comment 6

[Cristina Coroiu [:ccoroiu]]

Backed out changeset b71322e45143 (bug 1647681) for mochitest failures at toolkit/components/url-classifier/tests/mochitest/test_classify_top_sandboxed.html

Backout: https://hg.mozilla.org/integration/autoland/rev/4615ddce56a6da17a623d5c7b12a489f6fe6bda6

Failure push: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=b71322e4514352cdd60ad1b12576d867aa4b4bbd

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=310959111&repo=autoland&lineNumber=10815

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/eafe39231edd

Comment 8

[Johann Hofmann [:johannh]]

This doesn't have to be confidential anymore, the fix shipped.