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

On 02/04/13 12:30, Dave Raggett wrote:
>
> My assumption is that for a signed app, the browser/web run-time can 
> check the integrity of the app's components, and can also check the 
> signature via a query against the origin declared in the app's manifest.
>
> The origin check, to use Robin's terminology, should be resistant to 
> man in the middle attacks. My perhaps naive suggestion would be to ask 
> the server to sign something suitable** provided in the query, so that 
> the browser can verify that it has been signed with the same public 
> key as was used for signing the manifest. Presumably the public key 
> should itself be part of the manifest. If that key is revoked the app 
> would need to be reinstalled. 

Much of this discussion seems to be reinventing certificates and 
signatures using transport-level encryption. For instance: if you host a 
public key at a pre-set path on a particular origin, using a secure 
channel, this is largely equivalent to having a certificate for that key 
signed by the origin's SSL key.  Similarly, having a protocol whereby 
the origin asserts that certain application digests are 'authentic' is 
equivalent to having the application digest signed by the origin's SSL 
key.  I am of course assuming that this is all happening in secure 
transport sessions - otherwise the security guarantees vary wildly 
depending on the network and protocol chosen.  I don't know if that is 
the intention.

You're trading off the benefits of certificates - offline processing, 
efficiency, ability to protect the private key, reuse of existing 
standards - for benefits of a runtime protocol - no new keys needed, 
simpler tools, no additional parties, and so on.

I suspect that TOCTOU issues when doing this would need more thought in 
the security model.


On 02/04/13 17:59, Dave Raggett wrote:
> However, signing the byte sequence forming the downloaded manifest 
> file sounds much easier and would protect against a man in the middle 
> attack when checking with the origin server. I think this needs the 
> server's public key to be included in the manifest, but there isn't a 
> need for signing the packaged app up front, which should alleviate 
> your concern.

I'm sorry Dave, but I'm not sure I understand what you're proposing... 
hopefully my earlier comment will make some sense.

>
> If as suggested we have a list of permitted IRIs for XHR and web 
> sockets, this could be confirmed at install time by checking with the 
> server associated with the alleged origin that this manifest, and by 
> implication, this packaged app is to be trusted for this origin and 
> access to those hosts.

This is effectively using CORS to cope with application manifests, 
right?  That seems reasonable.

>
> You could then download the packaged app from anywhere, and be able to 
> confirm that it hasn't been tampered with, and is in fact the same as 
> the app that the origin server vouches for.

My only extra thought here is - if you're just talking about manifests, 
you need to have some link between the manifest and the content, 
otherwise a legitimate manifest could be used with a rogue package or 
hosted content.  It isn't clear how this would be achieved yet, but 
perhaps this is obvious and I can't see it in the runtime spec.

Best wishes,

John

Received on Wednesday, 3 April 2013 11:47:18 UTC