Same-origin policy on Presentation API?

Hi all,

We're currently working on the implementation of Presentation API [1]. And
here comes a concern about the same-origin policy with Presentation API.

The current road map for Presentation API on Firefox OS is as follows [2]:

1. For now, we should make Presentation API available for packaged apps on
Firefox OS because the API spec is still unstable. Therefore, the WebIDL
should use Pref + AvailableIn="PrivilegedApps".

2. When spec is stable, we can make it available to web pages on Firefox
OS. |AvailableIn="PrivilegedApps"| can be removed in this stage.

3. When our implementation is stable, we can make it available to all
platform. Preference |dom.presentation.enabled| can be default on for all
platform.

So if we enforce same-origin policy when starting a presentation session
with a given URL, under the current app protocol, the sender app won't be
able to ask the receiver (the presenting device) to open any http/https
URL. Besides, the sender and receiver must be the same app. Not sure if
this would restrict some potential applications too much.

On the other hand, if it allows cross-origin, it might arouse security
concerns once we make it available on all platforms (stage 3 in the road
map), since a web page at the sender side can freely ask the receiver to
open any URL.

Thus we're wondering whether it's appropriate to have same-origin within
Presentation API context. And if it's necessary to apply it, should we have
it at the very beginning or another specific point in the road map?

Btw, there's a similar discussion about the origin relationship in
Presentation API spec [3]. But there's still no conclusion so far.

Sean Lin
Mozilla Taiwan
[email protected]

[1] http://w3c.github.io/presentation-api/
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1069230#c23
[3] https://github.com/w3c/presentation-api/issues/63

I'm not super familiar with the Presentation API so sorry if this
question is obvious, but what are the risks that we're worrying here
about same-origin policy? Does the Presentation API enable something
more than window.open()'ing a cross-origin document and postMessage()ing
to it?
> _______________________________________________
> dev-webapi mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-webapi
>

There is a precedence, in which you are allowed to set "location.href"
for cross-origin windows if you have a handle for them (e.g. through
window.open(), opener or a frame element).

Can the Presentation API can set the URL for another web page (tab?
window? popup? I don't know), _without_ having a handle? If yes, it
should be limited to the same origin.

(I assume that the Presentation API does not cause requests on the HTTP
layer, otherwise CORS would be an interesting thing to look at :-))

Generally they are quite similar. The major difference is Presentation API
is across devices. But the current Presentation API doesn't have a way to
specify the target origin when posting messages like window.postMessage().
So assuming same-origin policy is enforced on Presentation API, if a sender
is allowed to open a cross-origin page, then there will be no way for
follow-up cross-origin communications with the receiver.

We're trying to figure out a reasonable tradeoff between the security
provided by same-origin policy and the usability of Presentation API. Maybe
it's another way to send feedback to the working group so that Presentation
API may specify the target origin for messaging. Then same-origin policy
can fit in without restricting the use of Presentation API too much.

Thoughts?!

Sean

On Wed, May 6, 2015 at 2:25 AM, Ehsan Akhgari <[email protected]>
wrote:

Just like Sean says, we can use Presentation API to open a window on remote
device, so it's very similar to do postMessage() to a cross-origin document
on another process.

For the usability of Presentation API, we would like to allow web developer
to create a receiver app (e.g. video player) that allows other websites to
use it. We can imagine that this receiver app to use send/onmessage to
implement the remote media control UI.

If we simply follow the same-origin policy for postMessage, this means
receiver app will not be able to communicate with the remote page which is
not in the same origin.

I'll suggest that we add one more |targetOrigin| parameter to
session.send(), which similar to window.postMessage() [1].

session.send(message, origin); // "*" can represent no origin check

Therefore, UA can allow cross-origin communication but also prevent message
to be delivered to unexpected endpoint.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

I still don't see the issue. Let's imagine that we have devices A and
B, A loading a webpage from evil.com which uses the presentation API to
open a window on B to a URL and postMessage to it. Presumably the risk
is that the URL to open on B would be to site.intranet, so evil.com
would get a postMessage based channel to site.intranet. But what can it
do with that channel? By definition, any communication will require
cooperation from site.intranet, right?
Why? postMessage itself works fine cross origin...
Ah yes, I was assuming that when we talk about postMessage(), such a
mechanism is available. Without that, site.intranet cannot choose to
not communicate to evil.com, and only talk to goodguy.com.

Hi Ehsan,

The WG had a f2f discussion on this issue last week. This proposal was
rejected due to following 3 reasons:

1. Currently, opening a page that creates datachannel to remote doesn’t
have cross-origin restriction while sending message. Presentation API can
just follow the same security constraint.

2. For receiver side, the origin of requesting page cannot be validated.
Extra “targetOrigin” check doesn’t increase the security level because
remote peer might be compromised. Web developer will do their own check
with server side support, e.g. validate authentication key in server, if
security is critical to their app.

3. Connecting to a web page (which is loaded in privacy mode) cannot get
any valuable data. Only connecting to packaged app (which is Gecko only)
can leak important information because packaged app can use privileged
APIs. Mozilla can have our own extension to resolve the issue.

I kind agree with those arguments but might have bind spot. May I know your
two cents on these feedback?
On Thu, May 7, 2015 at 9:24 PM, Ehsan Akhgari <[email protected]>
wrote:

Are you referring to the DataChannel API? I wonder how that works securely...
They can't trust the browser?
This sounds like a fundamental misunderstanding of the same-origin
policy. See https://annevankesteren.nl/2015/02/same-origin-policy for
an explanation of what is protected beyond pages shielded by
credentials.


--
https://annevankesteren.nl/

Yes I'm referring to the DataChannel API. WebRTC DataChannel support DTLS
so we are able to defend passive attack (packet sniffer).
The remote endpoint is not necessary a browser, thus we cannot have any
guarantee in general.
The initial question includes "should we allow evil.com to request a
presentation for a page in example.com?" This is more close to the issue
described in your blog post, I think. We consider this will not cause any
cross-origin issue because both the browsing context (DOM) and rendering
context are separated (just like web page on two tabs).
So the next question is "how should we build a secured mechanism for these
two pages to communicate?" because we want to have a message-based
mechanism for application to define their own interaction.

>
>
> --
> https://annevankesteren.nl/

You can also defend against an active attacker if you want to use the
identity provider.

How does that protect resources behind a firewall?
That seems fair.
Seems like we should reuse the postMessage() API for this, but that
was already suggested and rejected for unclear reasons...


--
https://annevankesteren.nl/

There's a consent check based on ICE (RFC 5245) that stops you from
connecting
to arbitrary other endpoints. See:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-4.2
and
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-11#section-5.3

-Ekr

> [1] https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Hi Shih-Chiang,

Yeah, I think this looks good.

As I understand it there are two separate concerns here.

1. Should we allow opening a cross-origin URL using the Presentation API?

I think this is similar enough to simply navigating to a cross-origin
URL, or opening a cross-origin URL in an <iframe>, that I think this
is totally fine.

It's possible that we should enable websites to opt out of being
displayed on a TV through a CSP directive, but I think we can worry
about that later.

2. Do we need a way to ensure that messages can be safely sent to a
given origin.

As I understand it, the concern here is that website a.com opens
website b.com on a TV, and then uses session.send(message) to send it
some sensitive information.

However website b.com might have navigated to website c.com before the
message arrives.

I think adding a second 'origin' argument to session.send() makes
sense, like in your proposal.

However we should think about how we should handle page navigations in
general. If page A opens page B on the TV, but page B does a
navigation to page C which A did not expect then it seems like things
could very easily break.

First off it seems like messages that A intended to go to B now might
end up going to C.

Second, messages that B meant to not receive but that should instead
be handled by C might end up going to B depending on how quickly C
loads.

The latter problem could be helped by enabling B to signal when it is
and when it isn't ready to receive messages, and then have browser
queue messages when the current page isn't ready to accept them.

/ Jonas

Thanks! This is a good suggestion. I can raise this question once we have
come out some concrete use cases.
IMO the session object should not appear in c.com after navigation. In this
case there is no way c.com can receive the remote message, without adding
'origin' argument. It seems a weird use case to support a controlling page
can talk to multiple websites seamlessly within a single session.

For such kind of page navigation requirement, I would imagine a.com opens
a.com/presenter on TV. Then, use the message channel to open b.com in
iframe in a.com/presenter.