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

On Wednesday, 3 April 2013 at 04:47, John Lyle wrote:

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

The security model should be consistent for the whole application, not on a per API basis IMO. That is, we should not just fake the origin for XHR, but for the whole application. When required, that would make packaged apps behave in a way that is indistinguishable from hosted apps. 

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

I don't think it's obvious. You still need to sign both the content of the package and the manifest itself. The runtime spec does not cover this AFAICT.

Received on Sunday, 7 April 2013 20:01:44 UTC