> 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 <ladam...@mozilla.com> wrote: > Please reply-to dev-weba...@lists.mozilla.org > > 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 > dev-web...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-webapi _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
