postMessage from iframe cannot securely send to extension content-scripts in different frame

REOPENED
Unassigned

Status

defect
P3
normal
REOPENED
3 years ago
6 months ago

People

(Reporter: bugzilla.mozilla.org, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: triaged)

Reporter

Description

3 years ago
Since each content script is scoped to the domain of the |window| it is attached it cannot directly manipulate cross-origin frames and has to talk to separate content scripts attached to those frames.

But securely talking to those other content scripts is fairly difficult.

Attempting to use standard web APIs fails, e.g. top.postMessage("foo", "moz-extension://...") fails with the following error:

> Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘moz-extension://...’) does not match the recipient window’s origin (‘https://www....’).


Expected behavior:

a) The message is sent anyway and can only be received by by the content script in the other frame
b) the message's |origin| is set to postMessage's |targetOrigin| if it's sent from an expanded principal and received on an expanded principal and both principals subsume targetOrigin.

In other words, when sending from a content script to a content script then both ends can be sure that only the content script was able to see it and not the page content.
Is this a regression?
Reporter

Comment 2

3 years ago
No.
Component: DOM → WebExtensions: Untriaged
Product: Core → Toolkit

Updated

3 years ago
Priority: -- → P3
Whiteboard: triaged
IIUC what is being attempted here, runtime.sendMessage can be used.
Status: UNCONFIRMED → RESOLVED
Closed: Last year
Resolution: --- → INVALID
Reporter

Comment 4

Last year
I can't scope sendMessage's target to a specific window, so it seems like it would be quite inefficient due to broadcasting every event.

Updated

Last year
Product: Toolkit → WebExtensions
Not sure why this was closed. This is definitely something we ideally want. runtime.sendMessage is harder to target and has higher latency. We should make it as easy as possible for extensions to do the Right Thing.
Status: RESOLVED → REOPENED
Component: Untriaged → General
Ever confirmed: true
Resolution: INVALID → ---

Comment 6

6 months ago
I ran into this while trying to port Shumway to WebExtensions, since it uses window.postMessage to send data back and from the different rendering iframes and, during startup, the content script of the embedding page.
Blocks: webext, 1451083
See Also: → 1208775
No longer blocks: webext
You need to log in before you can comment on or make changes to this bug.