1492607 - Prevent postMessage communication across first-party when restrict_opener_access = true

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[Arthur Edelstein [:arthur]]

STR:

Set "privacy.firstparty.isolate" to true.
Set "privacy.firstparty.isolate.restrict_opener_access" to true.

Open https://torpat.ch in a new tab.

In the web console, enter
  let myWindow;
  document.addEventListener("click", () => myWindow = window.open("https://arthuredelstein.net"));

Now click on the torpat.ch document and a new tab opens.

  In the web console for each tab, write:
  window.onmessage = e => console.log(e);

Now in the torpat.ch console, enter:
  myWindow.postMessage("hello from torpat.ch", "*");

In the arthuredelstein.net console, enter:
  window.opener.postMessage("hello from arthuredelstein.net", "*");

Expected results:
  Communication should not happen between documents with a different first-party.

Actual result:
  Messages can be passed in both directions.

Note: We should check the case where iframes open a new tab as well.

Comment 1

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

This seems like it has a very good chance of breaking FPI login flows. (ni-ing Steve just in case he happens to know off the top of his head based on his prior investigation.)

For the benefit of our users who have FPI turned on, I think we should be conservative with this change and make it preffed off by default.  Granted, FPI is not a supported feature, but we appreciate the bug reports people provide about it, and annoying them all seems detrimental if it's easily avoidable. Also, it will give us an opportunity to slowly roll it out to ourselves and early testers and collect bug reports while not being deluged.

Comment 2

[Arthur Edelstein [:arthur]]

One idea we discussed, to mitigate the breaking of login flows, is to pop up a permissions doorhanger whenever either tab attempts a postMessage. The doorhanger can ask the user: "Would you like A.com to share information about you with B.com?" Then, depending on the user's answer, the message is either allowed to proceed or canceled.

This idea takes advantage of the asynchronous behavior of postMessage. I don't see any easy solution for synchronous access via window.opener.document.

Comment 3

[Tim Huang[:timhuang]]

Attachment: Bug 1492607 - Part 1: Making postMessage to be aware of OAs when the targetOrigin is "*."

Comment 4

[Tim Huang[:timhuang]]

Attachment: Bug 1492607 - Part 2: Add a test case for assuring postMessage cannot post across OAs

Depends on D8521

Comment 5

[Tim Huang[:timhuang]]

Per discussion with Baku, we are not 100% sure about entirely blocking the postMessage across for FPI in our side since it may break websites, like SSO. But we pretty sure that Tor wants this, so I will add a pref for controlling the blocking behavior here.

Comment 6

[Tim Huang[:timhuang]]

It turns out this patch breaks a bunch of tests. Most of the cases are the chrome wants to post messages to content to do some test. For example, a browser chrome test uses ContentTask.spawn() to inject code to post a message to a private browsing window. Because of the injected code will be executed under the system principal and its OA mismatches with the OA of the private browsing window. So, it will hit the assertion.

I would suggest that we skip the check if the subject principal is the system principal.

Comment 7

[Tim Huang[:timhuang]]

Attachment: Bug 1492607 - Part 3: Exempting the check of OAs for postMessage with the target origin is '*' if it is coming from the system principal

It turns out that many tests are going to post Messages to content
from chrome with a mismatched OA. This patch exempt the check in that
case.

Depends on D8522

Comment 8

[Tim Huang[:timhuang]]

Try looks good.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a2053137e776fa5063cceac91675f7b7f1366326

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dfc3795ef568
Part 1: Making postMessage to be aware of OAs when the targetOrigin is "*." r=arthuredelstein,baku
https://hg.mozilla.org/integration/autoland/rev/0b4b3d826b3f
Part 2: Add a test case for assuring postMessage cannot post across OAs r=arthuredelstein,baku
https://hg.mozilla.org/integration/autoland/rev/44cd913c18f8
Part 3: Exempting the check of OAs for postMessage with the target origin is '*' if it is coming from the system principal r=baku

Comment 10

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/dfc3795ef568
https://hg.mozilla.org/mozilla-central/rev/0b4b3d826b3f
https://hg.mozilla.org/mozilla-central/rev/44cd913c18f8