Security/Reviews/CrossOriginEventSource

Introduce Feature

Allow Cross-Origin URLs in EventSource (Server-Sent Events) - bug 664179

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

Push-based event triggers, based on CORS/XHR stuff. Syntax sugar to make push and event notifications easier and require less scripting support for connection maintenance, etc.

We already have support for Server Sent DOM Events. This was done in bug 338583 and security review happened in ServerDomEvents

The goal of this feature is to allow cross-site pushing of server sent events. For example allowing a bank site to push events that keep you up-to-date with your portfolio, or facebook pushing an event stream containing updates to your wall. http://pulse.mozilla.org/ has also expressed desire to use this to allow other sites to consume and visualize data concerning the mozilla project.

• bug 664179 Tracks the cross-site support
• There appears to be agreement between all concerned parties that CORS will be used as security model.

Any security threats already considered in the design and why?

• Credential (cookies) use without target site expecting it (CSRF).

The threats are the same as for cross-site XMLHttpRequest.

• Sites might share data without first checking with the user that this is ok.
• Sites might accidentally share data with third party sites while not intending to do so.
• The data can be sniffed while going over the net.

There are lots of mitigations built into CORS which is used as security model

• Can only opt in on a per-URI basis (though serverside technologies can make this available on a per-site or per-subtree basis)
• Can't opt in to sharing private data with "the world" without using custom server-side scripting which echos back the "Origin" header in the "Access-Control-Allow-Origin" header.
• Sharing private data requires setting two explicit headers: "Access-Control-Allow-Origin" and "Access-Control-Allow-Credentials".

Additionally, we're reusing the same code as used for cross-site XMLHttpRequest, cross-site @font-face, CORS-based <img>.

Topics To Discuss During The Review

Please be prepared to discuss the topics listed at ReviewTopics as they relate to your feature / project. Optionally, you may copy the most relevant questions here and answer them before the review, which could speed up the review meeting.

CORS can be used in two "modes". With credentials, such as cookies, and without. The big controversial issue is weather to default EventSource to use cookies when going cross-site, or if that should be opt-in. XHR requires opt-in. Hixie has argued that the use cases for not using cookies are weak enough that we should simply not support it, thus the default, and only mode, would be to send cookies.

Threat Brainstorming

The threat model is largely the same as for CORS and for EventSource, both of which have already been reviewed. However since CORS allows two "modes" in the form of with-cookies and without-cookies, we need to choose a strategy for which modes to allow and which mode to default to. Concern was raised that some sites might misunderstand what enabling CORS on their event-source stream means. There's a possibility that they understand it to mean that you can only use EventSource to read the stream. This might for example think that it's ok to put potentially sensitive information in comments in the stream. However since the full unparsed stream can be read using cross-site XHR, this is in fact not safe.

Conclusions / Action Items

Consensus was that we didn't want to force the "with cookies" mode on people that wanted to use the cookie-less mode of CORS. We further believe that some sites will want to use cookies, and this should be allowed as well. This rules out any solution that doesn't allow choosing between the with-cookies and without-cookies model. We further wanted to use the same defaults as XHR of using cookie-less requests. One big reason for this was that rather than guessing at how common cookie-less vs. with-cookies are, we'd stick with the model established by XHR. Hence we should default to not sending cookies and enable the ability to opt-in to cookies. If other implementations go other ways we can reevaluate this decision at a later point. To mitigate the risk of misunderstanding what it means to opt in to CORS (i.e. that you're opting in to more than just cross-site EventSource) we should make sure to make it clear in documentation that enabling CORS on a stream exposes the full contents of the stream to the loading site. While we could attempt to mitigate it through technical means, the added complexity likely adds further risks of misunderstandings.