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