Same-origin policy on Presentation API?

[Sean Lin]

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
se...@mozilla.com

[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

[Ehsan Akhgari]

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
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>

[Frederik Braun]

On 05.05.2015 10:20, Sean Lin wrote:
> 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.

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 :-))

[Sean Lin]

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 <ehsan....@gmail.com>
wrote:

> 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?
>
>
> On 2015-05-05 4:20 AM, Sean Lin wrote:
>
>> 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.
>>

[Shih-Chiang Chien]

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

[Ehsan Akhgari]

On 2015-05-06 3:23 AM, Shih-Chiang Chien 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.

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?

> 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.

Why? postMessage itself works fine cross 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.

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.

[Shih-Chiang Chien]

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?

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Thu, May 7, 2015 at 9:24 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

[Anne van Kesteren]

On Wed, May 27, 2015 at 3:52 PM, Shih-Chiang Chien <sch...@mozilla.com> wrote:
> 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.

Are you referring to the DataChannel API? I wonder how that works securely...

> 2. For receiver side, the origin of requesting page cannot be validated.

They can't trust the browser?

> 3. Connecting to a web page (which is loaded in privacy mode) cannot get
> any valuable data.

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/

[Shih-Chiang Chien]

On Sat, May 30, 2015 at 7:21 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Wed, May 27, 2015 at 3:52 PM, Shih-Chiang Chien <sch...@mozilla.com>
> wrote:
> > 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.
>
> Are you referring to the DataChannel API? I wonder how that works
> securely...
>

Yes I'm referring to the DataChannel API. WebRTC DataChannel support DTLS
so we are able to defend passive attack (packet sniffer).

>
>
> > 2. For receiver side, the origin of requesting page cannot be validated.
>
> They can't trust the browser?
>

The remote endpoint is not necessary a browser, thus we cannot have any
guarantee in general.

>
>
> > 3. Connecting to a web page (which is loaded in privacy mode) cannot get
> > any valuable data.
>
> 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.
>

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/

[Martin Thomson]

On Mon, Jun 1, 2015 at 2:52 AM, Shih-Chiang Chien <sch...@mozilla.com> wrote:
> Yes I'm referring to the DataChannel API. WebRTC DataChannel support DTLS
> so we are able to defend passive attack (packet sniffer).

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

[Anne van Kesteren]

On Mon, Jun 1, 2015 at 6:52 PM, Shih-Chiang Chien <sch...@mozilla.com> wrote:
> Yes I'm referring to the DataChannel API. WebRTC DataChannel support DTLS
> so we are able to defend passive attack (packet sniffer).

How does that protect resources behind a firewall?

>>> 3. Connecting to a web page (which is loaded in privacy mode) cannot get
>>> any valuable data.
>>
>> 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.
>
> 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).

That seems fair.

> 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.

Seems like we should reuse the postMessage() API for this, but that
was already suggested and rejected for unclear reasons...


--
https://annevankesteren.nl/

[Eric Rescorla]

On Mon, Jun 1, 2015 at 4:20 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Mon, Jun 1, 2015 at 6:52 PM, Shih-Chiang Chien <sch...@mozilla.com>
> wrote:
> > Yes I'm referring to the DataChannel API. WebRTC DataChannel support DTLS
> > so we are able to defend passive attack (packet sniffer).
>
> How does that protect resources behind a firewall?

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

>
> >>> 3. Connecting to a web page (which is loaded in privacy mode) cannot
> get
> >>> any valuable data.
> >>
> >> 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.
> >
> > 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).
>
> That seems fair.
>
>
> > 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.
>
> Seems like we should reuse the postMessage() API for this, but that
> was already suggested and rejected for unclear reasons...
>
>
> --
> https://annevankesteren.nl/

[Jonas Sicking]

On Wed, May 6, 2015 at 12:23 AM, Shih-Chiang Chien <sch...@mozilla.com> 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

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

[Shih-Chiang Chien]

Thanks! This is a good suggestion. I can raise this question once we have
come out some concrete use cases.

> 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
>

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.