Re: [sysapps/runtime] cross origin XHR in packaged apps

On Tue, Apr 2, 2013 at 3:46 AM, Robin Berjon <robin@w3.org> wrote:
> On 01/04/2013 15:26 , Jonas Sicking wrote:
>>
>> First off I think we should enable some way for packaged apps to be
>> same-origin with their "home site". I.e. if a developer running a
>> website on http://www.example.com it should be possible for this
>> developer to somehow distribute a packaged app that is same-origin
>> with http://www.example.com.
>
>
> That would indeed be great.
>
>
>> There's some discussion around the challanges with this in [1].
>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=852720
>
> Yes, it's a tricky problem. We've been through those discussions before, we
> even got a Recommendation out of it: WARP
> (http://www.w3.org/TR/widgets-access/).
>
> Not that I'd necessarily recommend we use it.
>
> Reading through that bug, there are several motley things that come to mind,
> so here are my notes in no particular order.
>
> First, I have to say that I'm always concerned when I read about differences
> in behaviour between packaged and hosted apps when such differences go
> beyond things that fall more or less directly out of packaging.

I'm not sure what differences you are referring to here.

In that bug I'm specifically arguing against using methods that rely
on trusted signatures, since such signatures forces developers to go
through trusted stores.

> I think that we should strive as much as possible for packaging to be
> orthogonal to the application concept. It should be possible to use
> packaging for an arbitrary web site (perhaps as an optimisation), including
> just for dependencies in the same way that it should be possible to install
> a hosted app. The only impact that packaging should have is on retrieval and
> (possibly) on signing. IMHO any other behaviour difference between hosted
> and packaging will lead to madness.

I completely agree. That's the case in the currently defined security
model as far as I can tell. That an the issue that we're trying to
resolve here of how to assign origins.

> When it comes to assigning an arbitrary origin to an installed app, it's a
> worthy goal.

Note that the only issue here is packaged apps. Hosted apps inherently
have an origin.

> Having mulled this over, I have yet to think of a secure way in which this
> could happen without involving cooperation from the origin server. I don't
> really see how a CORS-like header would be useful on its own — I may be okay
> with *my* app accessing my site, but not others; and if I want CORS I can
> use CORS. Anything involving signatures through third parties tends to
> inherently suck.

Agreed. I definitely think we should rely on the origin server.

What do you think about the solution that's discussed in the bug.
Using the origin that hosts the app package as long as that package is
served with some specific header, such as a specific mimetype.

> At the same time, this need to be really easy to deploy on the server. It
> should be possible to drop in some PHP/Node module/whatever, give it a
> pointer to the app, and all should be rosy. You could have something like
> this in the manifest:
>
>     "originCheck": "http://sicking.cc/check-app/"
>
> The runtime would then hit that URL in order to figure out if the app is
> allowed to use that origin. The exact details of the protocol depend on what
> we want to defend against. The endpoint can't just return 200 or echo
> something it's given because otherwise it's too easy to just hijack an
> existing service. It should at the very least perform some computation on
> the input. For instance, it could get a hash of the manifest and a nonce
> from the runtime, and return something based on those.

This is indeed a very interesting idea. I'd love to see a full
proposal. Possibly sending the hash of the package to the origin-check
URL and having the url return some specific response would work.

>> However I also like the idea of enabling a privileged app to do
>> network connections to a white-list of website. So basically a variant
>> of the Firefox OS systemXHR and tcpsocket that only allows requests to
>> a particular set of websites. This would be strictly more secure than
>> what Firefox OS does now.
>>
>> This could be accomplished by adding additional information to those
>> permissions in the manifest. So something like:
>>
>> permissions: {
>>    systemXHR: {
>>      description: "...",
>>      servers: ["https://www.foo.com", "https://www.bar.com"]
>>    }
>> }
>
>
> Ah, so that's basically reinventing WARP :) One thing I've come to wonder
> about over time is whether that level of granularity is truly useful.
> Whitelisting certainly mitigates against intranet attacks, but it's not so
> complex to poke holes in there: all you need to have is an application that
> can justifiably request access to everything (e.g., an RSS reader), which
> doesn't require all that much imagination. So I tend to think that if
> there's going to be a privilege to poke holes in the SOP, then it might just
> as well be boolean.

In general I would say it's beneficial to lock down the capabilities
that are extended to an app. That's why we separate the various
permissions rather than give all privileged apps all the permissions
that privileged apps can ask for.

So if there are *common* use cases for wanting systemXHR or TCPSocket
or UDPSocket access to only certain domains/origins, then I think
that's something we should look at. But I don't know of any right now.

/ Jonas

Received on Wednesday, 3 April 2013 07:12:05 UTC