- From: Philippe De Ryck <philippe.deryck@cs.kuleuven.be>
- Date: Mon, 01 Aug 2011 16:13:45 +0200
- To: public-html-comments@w3.org
- Cc: Giles Hogben <Giles.Hogben@enisa.europa.eu>, Lieven Desmet <Lieven.Desmet@cs.kuleuven.be>
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
Received on Tuesday, 2 August 2011 09:06:54 UTC