WebAPI Security Discussion: Browser API

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

WebAPI Security Discussion: Browser API

Lucas Adamski-2
Please reply-to [hidden email]

Name of API: Browser API
Reference: https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI

Brief purpose of API: Provide an iframe that acts as a web browser
General Use Cases: None

Inherent threats:
* browser can see all data from all websites, and perform all actions

Threat severity: moderate (phishing) per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: None
Authorization model for normal content: None
Authorization model for installed content:None
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including  OAuth, OpenID, PayPal, Facebook Connect, etc. etc.
Authorization model: implicit
Potential mitigations: container should not be able to script into browser iframe

Google's recommendations about how to do this:
http://sites.google.com/site/oauthgoog/oauth-practices/auto-detecting-approval

Consider also the iOS-Twitter authorization flow described here:
http://code.google.com/p/twitter-api/issues/detail?id=1560
and the threat, described here:
http://www.zdnet.co.uk/blogs/tech-tech-boom-10017860/ios-url-handler-poses-significant-risk-10021042/

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Replacement Browser
Authorization model: Implicit
Potential mitigations: Explicit process to add a new browser to the system?

[Given that the browser is built in to b2g, what would a replacement browser actually be?]

popup windows in b2g:
https://bugzilla.mozilla.org/show_bug.cgi?id=716664

window.open in iframe mozbrowser:
https://bugzilla.mozilla.org/show_bug.cgi?id=742944

window.open in iframe mozapp:
https://bugzilla.mozilla.org/show_bug.cgi?id=744451


_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Browser API

Justin Lebar-3
> Potential mitigations: container should not be able to script into browser iframe

In general, you cannot mitigate risk from an untrusted browser.

An untrusted browser can arbitrarily phish you.  You type in
"bank.com", the browser takes you to evil.com and displays "bank.com"
in its URL bar.  It even displays a lock icon.  You type in your
username and password.  Evil.com records it.

I think it is a mistake to talk about things like preventing the
container from injecting script into the iframe.  That is only useful
for preventing a tiny class of attacks out of many, many possible
attacks.

> Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including  OAuth, OpenID,
> PayPal, Facebook Connect, etc. etc.

<iframe mozbrowser> is explicitly not for this.  We need to be able to
run the mozbrowser in a separate process, and that precludes any
interaction of this sort between the parent and the child.

> [Given that the browser is built in to b2g, what would a replacement browser actually be?]

The browser is built in just like the calculator app.  A user could
download another calculator app.  They could also download another
browser app (modulo security constraints).

On Mon, Apr 16, 2012 at 4:14 PM, Lucas Adamski <[hidden email]> wrote:

> Please reply-to [hidden email]
>
> Name of API: Browser API
> Reference: https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
>
> Brief purpose of API: Provide an iframe that acts as a web browser
> General Use Cases: None
>
> Inherent threats:
> * browser can see all data from all websites, and perform all actions
>
> Threat severity: moderate (phishing) per https://wiki.mozilla.org/Security_Severity_Ratings
>
> == Regular web content (unauthenticated) ==
> Use cases for unauthenticated code: None
> Authorization model for normal content: None
> Authorization model for installed content:None
> Potential mitigations:
>
> == Trusted (authenticated by publisher) ==
> Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including  OAuth, OpenID, PayPal, Facebook Connect, etc. etc.
> Authorization model: implicit
> Potential mitigations: container should not be able to script into browser iframe
>
> Google's recommendations about how to do this:
> http://sites.google.com/site/oauthgoog/oauth-practices/auto-detecting-approval
>
> Consider also the iOS-Twitter authorization flow described here:
> http://code.google.com/p/twitter-api/issues/detail?id=1560
> and the threat, described here:
> http://www.zdnet.co.uk/blogs/tech-tech-boom-10017860/ios-url-handler-poses-significant-risk-10021042/
>
> == Certified (vouched for by trusted 3rd party) ==
> Use cases for certified code: Replacement Browser
> Authorization model: Implicit
> Potential mitigations: Explicit process to add a new browser to the system?
>
> [Given that the browser is built in to b2g, what would a replacement browser actually be?]
>
> popup windows in b2g:
> https://bugzilla.mozilla.org/show_bug.cgi?id=716664
>
> window.open in iframe mozbrowser:
> https://bugzilla.mozilla.org/show_bug.cgi?id=742944
>
> window.open in iframe mozapp:
> https://bugzilla.mozilla.org/show_bug.cgi?id=744451
>
>
> _______________________________________________
> dev-webapi mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-webapi
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Browser API

Ben Francis-7
In reply to this post by Lucas Adamski-2
On Mon, Apr 16, 2012 at 7:14 AM, Lucas Adamski <[hidden email]> wrote:

>
> == Regular web content (unauthenticated) ==
>
> == Trusted (authenticated by publisher) ==
>
> == Certified (vouched for by trusted 3rd party) ==
>

I don't understand these categories, could you explain them a bit further?

What is the difference between trusted and certified and what process and
limitations do they require?

Is there a difference in security model between regular web content and
installed apps?

If the app is installed directly from a web app's own server (not via a
third party app store), can it never get access to this API, even with the
user's explicit permission?

Ben

--
Ben Francis
http://tola.me.uk
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Browser API

Justin Lebar-3
> I don't understand these categories, could you explain them a bit further?

Lucas can correct me, but AIUI this is a model that Lucas has
developed for thinking about trust and apps.  These categories may not
have concrete analogs in B2G.

There was previously a lot of talk about somehow requiring that
"certified" apps be somehow restricted from executing arbitrary code,
so we could verify that they're doing what they say they're doing.
But that discussion has been put on hold afaict.

> What is the difference between trusted and certified and what process and
> limitations do they require?
>
> Is there a difference in security model between regular web content and
> installed apps?
>
> If the app is installed directly from a web app's own server (not via a
> third party app store), can it never get access to this API, even with the
> user's explicit permission?

In other words, these are good questions, but they're general
questions about this way of thinking about web app security, and
aren't specific to the browser API and this thread.  If we're going to
have this discussion, I'd appreciate if we did so separately.

-Justin
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Browser API

Lucas Adamski-2
In reply to this post by Ben Francis-7
Sorry I didn't catch this earlier.  The following discussion is still accurate, though I will refine these descriptions and post them to the wiki by Friday: https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/2dd02277ab8b41ba?pli=1
  Lucas.

On Apr 17, 2012, at 4:09 AM, Ben Francis wrote:

> On Mon, Apr 16, 2012 at 7:14 AM, Lucas Adamski <[hidden email]> wrote:
>
>>
>> == Regular web content (unauthenticated) ==
>>
>> == Trusted (authenticated by publisher) ==
>>
>> == Certified (vouched for by trusted 3rd party) ==
>>
>
> I don't understand these categories, could you explain them a bit further?
>
> What is the difference between trusted and certified and what process and
> limitations do they require?
>
> Is there a difference in security model between regular web content and
> installed apps?
>
> If the app is installed directly from a web app's own server (not via a
> third party app store), can it never get access to this API, even with the
> user's explicit permission?
>
> Ben
>
> --
> Ben Francis
> http://tola.me.uk
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: [b2g] WebAPI Security Discussion: Browser API

Lucas Adamski-2
On Apr 26, 2012, at 8:21 AM, Justin Lebar wrote:

> (cc only dev-b2g, per Mounir's plea that we stop mass cross-posting.)

I realize Mounir doesn't like cross-posting because doesn't want to be on all those lists, but I'm not sure why he thinks in turn everyone else should subscribe to his list just to participate in the API discussions.  If there's a single list these discussions should be happening on its dev-webapps not b2g.

This is different from most typical Mozilla discussions as it requires the participation of a broad set of stakeholders, all of whom should not be expected to subscribe to dev-b2g to participate.  I realize that sucks, but it sucks less than having a minority of people participating then having to restart the conversation when all of the other stakeholders are added.

>> The following discussion is still accurate
>
> No, it has a number of basic problems, which I pointed out in an
> earlier post.  Perhaps you missed it?

Huh?  My link was to the discussion of the types of applications per Ben's previous question, not directly related to browser API.  Sorry for the confusion.

> Here's what I'd written:
>
> ======
>
>> Potential mitigations: container should not be able to script into browser iframe
>
> In general, you cannot mitigate risk from an untrusted browser.
>
> An untrusted browser can arbitrarily phish you.  You type in
> "bank.com", the browser takes you to evil.com and displays "bank.com"
> in its URL bar.  It even displays a lock icon.  You type in your
> username and password.  Evil.com records it.
>
> I think it is a mistake to talk about things like preventing the
> container from injecting script into the iframe.  That is only useful
> for preventing a tiny class of attacks out of many, many possible
> attacks.

In this model the untrusted browser has access to the shared cookie and password stores, right?  This allows an app to load arbitrary website content and script into it, becoming a mass XSS and password stealing vector.  Not something I'd want every app to have access to, and the permission dialog would have to be carefully worded to communicate the risk.  Quite likely this would be unavailable to unauthenticated apps, and authenticated apps would have a pretty scary warning.

>> Use cases for authenticated code: Display remote content (e.g. from developer's site, or the contents of a tweet), or perform interactions with web-based services, including  OAuth, OpenID,
>> PayPal, Facebook Connect, etc. etc.
>
> <iframe mozbrowser> is explicitly not for this.  We need to be able to
> run the mozbrowser in a separate process, and that precludes any
> interaction of this sort between the parent and the child.

So is this really intended just for implementing browsers rather than interacting with content, and we can live with a fairly scary permission dialog (i.e. "has access to passwords and your private online data")?

>> [Given that the browser is built in to b2g, what would a replacement browser actually be?]
>
> The browser is built in just like the calculator app.  A user could
> download another calculator app.  They could also download another
> browser app (modulo security constraints).

Not as worried about calculator apps. :)
  Lucas.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: WebAPI Security Discussion: Browser API

Paul Theriault
In reply to this post by Lucas Adamski-2
(Final proposal, please reply to [hidden email] by COB
Jun 04)

Only change here was to change trusted apps from explicit to implicit,
acknowledging that trusted and certified apps will now have separate
profile based resources (cookie jars, localstorage, app-cache etc)

Name of API: Browser API
References:
https://wiki.mozilla.org/WebAPI/EmbeddedBrowserAPI
popup windows in b2g: https://bugzilla.mozilla.org/show_bug.cgi?id=716664
window.open in iframe mozbrowser:
https://bugzilla.mozilla.org/show_bug.cgi?id=742944
window.open in iframe mozapp:
https://bugzilla.mozilla.org/show_bug.cgi?id=744451

Brief purpose of API: Provide an iframe that acts as a web browser
General Use Cases: A browser app.

Inherent threats:
* browser can see all data from all websites, and perform all actions
* can steal passwords (user-entered; enumerate all saved passwords)
* can steal cookies (by enumerating websites)
* NOT a use case: OAuth or other app-content or content-content interactions

Threat severity: high per https://wiki.mozilla.org/Security_Severity_Ratings

== Regular web content (unauthenticated) ==
Use cases for unauthenticated code: None
Authorization model for normal content: None
Authorization model for installed content:None
Potential mitigations:

== Trusted (authenticated by publisher) ==
Use cases for authenticated code: Implement a 3rd party browser application
Authorization model: Implicit
Potential mitigations: Each app has separate cookie and password stores
from other apps (including system browser app)

== Certified (vouched for by trusted 3rd party) ==
Use cases for certified code: Replacement Browser
Authorization model: Implicit
Potential mitigations:


On 5/5/12 11:28 AM, Lucas Adamski wrote:

> On May 2, 2012, at 3:45 AM, Ben Francis wrote:
>
>> This also isn't a requirement, yet. This is definitely a tricky feature to implement and we've discussed it before but I would prefer to focus on the confirmed use cases first to make sure we don't build something that isn't needed (this could turn out to be part of the platform rather than the responsibility of any app for example, as many apps could benefit from this feature).
> Not allowing the container to have access to the content inside the browser definitely reduces the risk tremendously but also limits a lot of potential use cases.  Find is one of them but also typical browser features like adblocking, content blocking, content augmentation, etc.  Basically means no add-ons for 3rd party browsers.  I'm ok with that, but I suspect we'll come under a lot of pressure to permit this.  Happy to keep this out of 1.0 though.
>
>> My understanding of Open Web Apps is that anyone should be able to host their own app, without the involvement of a third party, the user can simply grant trust to the origin the app is being served from. Given that anyone can run their own app directory or app store, requiring that a "trusted" app be installed via a directory or store doesn't seem to add any extra protection in terms of security, just added complication for independent app developers.
> Trusted apps are different in a number of respects as documented in the "types of applications thread" (I'm also going to post this to the wiki to capture this more thoroughly).  Trusted apps have an explicit list of assets that is code reviewed and approved by an app store.  Only code enumerated in the manifest has access to granted privileges, etc.  Untrusted and trusted apps differ significantly beyond whether they went though an app store or not.
>
>> A third party app store can "vouch" for an app, or provide an indication of quality through user ratings which can help users to make a decision, but ultimately the user is expressing trust in the origin the app is served from, right?
> Or in the app store and review process.  That said I think you can still build very rich apps with untrusted apps, so I don't think we should frame this as an app store being required to build a great app.
>    Lucas.
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security