On Thu, Apr 12, 2012 at 12:36 PM, Mike Hanson <
mha...@mozilla.com> wrote:
> On Apr 12, 2012, at 10:55 AM, Benjamin Smedberg wrote:
>
>> SELF-AWARENESS:
>>
>> If we decide that apps should be allowed to know whether they are installed, for the purposes of showing or not-showing "install me" buttons: provide an .isInstalled(url) API.
>
> The original impetus of one-app-per-origin was because the security team advised me that we have no robust security perimeter other than domain - and that, if we were going to grant access to an API, we should do it at the level where we could be sure of the security properties of the caller.
I think that was a good initial design.
However I think at this point we're pretty sure that we need to
restrict access to sensitive APIs such that we don't grant permissions
to an origin no matter where it runs. Instead we grant permissions to
an origin only when it runs in a tab where we're running that specific
app. I.e. if a user has installed a facebook app which has elevated
privilege to access your calendar, we only grant access to pages of
the "
https://www.facebook.com" origin when it's running in the
"facebook app" tab, and only if it isn't contained by a cross origin
frame.
So in that scenario the "
https://www.facebook.com" origin doesn't have
any elevated privileges if you just browse to that domain. And it
wouldn't have elevated privileges even if the facebook app contains an
iframe which points to
www.othersite.com which in turn contains an
iframe to
www.facebook.com.
We need to do this anyway as to prevent granting access to an origin,
and then have that origin clickjacked. For example, I would be very
worried that my dialer app could get clickjacked if we didn't have
this policy.
> Maybe we lock down access to high-privilege APIs to be in top-level frames only, and we make sure the user always knows which app they are "in"
Yes. That's essentially it.
> but we don't have an SSL root-of-truth, just a bunch of string matching on the path. So anything that conceals or obscures the path could become an attack vector - directory traversals, homonym attacks, all that good stuff.
I'm not sure I follow this. Could you elaborate.
> Now, you could try to move the problem around, by saying high-privilege APIs can't be on shared domains - but in a self-publishing world, how do we enforce that? The user agent would have to check it, and it would be a bizarre error message for an end user to see ("you can't install AppA because AppB already has access to your microphone?")
For *really* high privilege APIs we will probably only enable the
privilege to pages that are listed in the app's appcache manifest.
This is because we'll require signatures for all resources to ensure
that the webserver hasn't been hacked. So for those APIs this won't be
a problem.
For other APIs it might be ok that a given page has access to for
example the camera API when loaded through one facebook app, but
doesn't have access to camera when loaded through another facebook
app. I can't think of a scenario where that would actually be a
problem.
> So, again, one-app-per-origin is a security restriction - which can be released if we have a robust solution for how to secure access to high-risk APIs. (and which is definitely part of the WebAPI security discussion that's happening right now in other threads!)
I think we do have such solutions.
/ Jonas