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

On Apr 8, 2013 10:11 AM, "Robin Berjon" <robin@w3.org> wrote:
>
> On 03/04/2013 08:44 , Jonas Sicking wrote:
>>
>> 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.
>
>
> That certainly works, but the downside is that packaged apps can't be
loaded through a third-party store, or side-loaded. At some point, that
sort of makes the point of packaged apps moot does it not?

If the developer of the packaged app doesn't have a web server where they
can host the app package, then they probably shouldn't be same-origin with
any server.

The same thing can be said for the checkOrigin property, it doesn't work if
the developer doesn't have a web server.

Note that just because you are being distributed through a third-party
store doesn't mean that the app package has to live there.

> I think that one of the greater values of packaged apps is user to user
sharing. Imagine I'm reading this great book that also has shared exercises
interacting with a community on its web site. I give the book to you on a
USB stick as we sit together on a long flight. But when you get off the
flight, the book works for me but not for you.

This is certainly an interesting use case, one that I haven't thought much
about.

However I think that use case is already broken. The way updates are
currently defined there is no requirement that the manifest inside the app
package contains enough information to enable downloading updates of the
package.

And from a security point of view, if it's not possible to update an app,
you should probably consider it broken.

The point I'm getting at is that we might be able to solve this by simply
requiring that enough metadata is available in the manifest in the package
that side loading becomes possible.

>>> 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.
>
>
> Before fleshing out a fuller proposal, I think it would be worth agreeing
on whether we should defend against developer stupidity (installing origin
checking endpoints that will just say yes) or not. The solution is
different depending on whether we need to defend against that or not. In
general I'm always in favour of giving people lots of rope, but since this
is security-sensitive I have some hesitations.

I don't think that there are any clear-cut answers here. I think one design
principle should be that it should be easier for authors to do the safe
thing than the unsafe thing.

Another issue is broken proxies. If the reply is a simple "yes"/"no", then
its very easy for that to get cached and reused when it shouldn't be. This
as something that we dealt a lot with in the design of CORS, so we can
probably look there for inspiration.

/ Jonas