This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13584 - [web messaging] Channel Messaging Origins
Summary: [web messaging] Channel Messaging Origins
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Web Messaging (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other All
: P3 trivial
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL: http://www.w3.org/mid/1312208025.2970...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-03 05:52 UTC by HTML WG bugbot
Modified: 2011-10-20 09:05 UTC (History)
8 users (show)

See Also:


Attachments

Description HTML WG bugbot 2011-08-03 05:52:30 UTC
public-html-comments posting from: Philippe De Ryck <philippe.deryck@cs.kuleuven.be>
http://www.w3.org/mid/1312208025.29701.38.camel@papyrus

The following comment contains detailed information about an issue that
was discovered during a recent security analysis of 13 next generation
web standards, organized by ENISA (European Network and Information
Security Agency), and performed by the DistriNet Research Group (K.U.
Leuven, Belgium).

The complete report is available at http://www.enisa.europa.eu/html5
(*), and contains information about the process, the discovered
vulnerabilities and recommendations towards improving overall security
in the studied specifications.

 Summary 
---------

If two browsing contexts X and Y create a messaging channel using ports,
no origin guarantees about the sender or receiver of the messages can be
given. This is in contrast with the 'Cross-document Messaging'
mechanism, where each message has a source and destination origin.

Based on: HTML5 Web Messaging, 7 July 2011
Relevant Sections: 5. Channel Messaging

 Issue
-------

Browsing context X creates two tangled messaging ports Px and Py, and
sends Py to context Y. When sharing a port using postMessage, both the
sender and receiver are explicitly identified. When sending messages
through these ports, the source and destination origin are not
explicitly available, but can be assumed to be the origins of sender and
receiver of the ports. This assumption does not hold if a browsing
context decides to further delegate a tangled port.

Concrete scenario:
1. Context X creates two tangled ports, Px and Py
2. X sends Py to context Y
3. Y sends Py to a third context Z
4. X sends a message through the port shared with Y, but the message is
received by Z

A similar scenario occurs when context X sends port Px to a third
context.

 Code example
--------------

The relevant pieces of code to suppor the scenario:

1. Creating and passing the port to context Y
	var channel = new MessageChannel();
	parent.frames[1].postMessage("port", [channel.port2],
"http://contextY.example.com");

2. Resending the port from Y to Z
	parent.frames[2].postMessage("port", [port],
"http://contextZ.example.com");
	
3. Sending a message using the original port
	port.postMessage("hello");

 Current state of implementation
---------------------------------

The current browser implementations show the following behavior:
	* Firefox 5: MessageChannel not supported
	* Chrome 12: Scenario is supported (arguments of port and destination
in postMessage are in wrong order)
	* IE 8:  MessageChannel not supported
	* Safari 5 (windows): Scenario is supported (arguments of port and
destination in postMessage are in wrong order)
	* Opera 11.50: Scenario is supported, origin of message is available
even with message channels (see potential solution 2)

 Recommended Solution
----------------------

The best solution is to explicitly include source and destination
origins for messages sent through a channel. The postMessage function
for message ports can be extended to include a destination origin.
Additionally, the MessageEvent for port messages can be required to
include the origin of the sender (field is currently available, but is
not used for 'channel messaging')



(*) HTML version of the report is available as well:
https://distrinet.cs.kuleuven.be/projects/HTML5-security/

-- 
Philippe De Ryck
K.U.Leuven, Dept. of Computer Science


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Comment 1 Ian 'Hixie' Hickson 2011-08-05 15:32:57 UTC
http://lists.w3.org/Archives/Public/public-html-comments/2011Aug/0026.html adds:

The intention of message channels being used in a capabilities model is
not at all clear from the spec. Seeing it in this light, I have two
additional comments:

1. It might be useful to mention this in the spec, so that this
mechanism is used as intended (instead of just as an easy way to use
two-way communication). Additionally, mention the consequences that this
can have (i.e. the granted right can be passed along)

2. I understand that in a capabilities model, the target origin cannot
be specified. I don't think that this holds for the source origin, so is
there a specific reason to not include the source origin in the message
(even though the attribute is available)?
Comment 2 Ian 'Hixie' Hickson 2011-08-08 21:54:31 UTC
I should add a non-normative section that talks about using MessagePort for exposing capabilities.


It doesn't make sense to expose the origin even for source, though, first because MessageChannel pairs are symmetric (there is no way to know which is the source) and secondly because even if there was, nothing stops an author from delegating the provision of a service to another origin, and we wouldn't want sites to break just because a service they rely on has switched to being provisioned by another origin.

It's also a potential privacy leak. Consider a case where someone invents a protocol for contact lists. Then they provide a generic interface that sites can communicate with to access the user's contact list, and the site proxies the requests to the site's Webmail service to actually provision the service by just passing its port along. If we expose source origins, third-party sites that just want to use this service can discover what Webmail service the user uses.
Comment 3 Ian 'Hixie' Hickson 2011-10-06 22:44:37 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: see above
Comment 4 contributor 2011-10-06 22:44:40 UTC
Checked in as WHATWG revision r6647.
Check-in comment: include information about the capabilities model
http://html5.org/tools/web-apps-tracker?from=6646&to=6647