Closed Bug 1492607 Opened Last year Closed Last year

Prevent postMessage communication across first-party when restrict_opener_access = true


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




Tracking Status
firefox65 --- fixed


(Reporter: arthur, Assigned: timhuang)


(Blocks 1 open bug)


(Whiteboard: [domsecurity-backlog1])


(3 files)


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

Open in a new tab.

In the web console, enter
  let myWindow;
  document.addEventListener("click", () => myWindow =""));

Now click on the document and a new tab opens.

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

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

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

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.
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.
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 to share information about you with" 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.
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Assignee: nobody → tihuang
Attachment #9016626 - Attachment description: Bug 1492607 - Part 2: Add a test case for assuring postMessage cannot post across OAs when the targetOrigin is "*." → Bug 1492607 - Part 2: Add a test case for assuring postMessage cannot post across OAs
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.
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.
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

Depends on D8522
Pushed by
Part 1: Making postMessage to be aware of OAs when the targetOrigin is "*." r=arthuredelstein,baku
Part 2: Add a test case for assuring postMessage cannot post across OAs r=arthuredelstein,baku
Part 3: Exempting the check of OAs for postMessage with the target origin is '*' if it is coming from the system principal r=baku
You need to log in before you can comment on or make changes to this bug.