Security/B2G/Browser API

Project Info

Security Information

This is a proposal for a Browser API and a new HTML element called "<browser>", which is similar to an iframe but allows the implementation of a fully featured web browser as a web app. As it currently stand, this is implemented as an attribute of the existing iframe tag (<iframe mozbrowser> however this may change eventually (bug

Background

Goals

• Provide support so that a Browser can be implemented as a Web App
• Makes the iframe appear like a top-level browser window to the embedded content
• Provide an API for parent page to manipulate and listen for changes of the embedded content's state.

Specification:

• https://wiki.mozilla.org/WebAPI/BrowserAPI

Bugs:

• https://bugzilla.mozilla.org/show_bug.cgi?id=693515

Pages:

• https://developer.mozilla.org/en-US/docs/DOM/Using_the_Browser_API

Source:

• http://mxr.mozilla.org/mozilla-central/source/dom/browser-element

Architecture

At its core, the browser creates a special type of iframe

Data Flow Diagram

Answered Questions

Open Questions

• Will there be a separate cookie store for <iframe mozbrowser>, or will they be shared?
• What will new window behavior be? (new tab?)

Threat Model

Threat vectors:

• Untrusted content escaping the <iframe mozbrowser> element
  • Javascript references to items not inside the iframe
  • Attacking local web apps through shared resources (are there any?)
  • Causing the parent frame to navigate
  • Obtaining the permissions of the parent frame, ie being able to act like a browser
    • Impact is minimal is API is kept limited - not sure if this will be possible

• Normal Browser Security controls weakened or not present
  • URL Bar behavior? (need to expose SSL information)

• Frame related issues
  • Must handle frame-busting code correctly
  • Modal dialogs in the browser frame must not block parent page

• Untrusted web page content not segregated sufficiently from Web Apps
  • Shared resources between untrusted content (i.e. page loaded in the mozbrowser) and the installed apps. Cookies?
  • Other Origin based resource access (local storage, Indexed DB)
  • DoS attacks against the phone (mitigated by seperate process, but what about spamming functions which result in IPDL messages back to the B2G process? Especially for messages that result in costly functions)
  • Permissions (what prevents a page loaded at sms.gaiamobile.org from getting SMS permissions?)

• Untrusted page might gain access to create an <iframe mozbrowser>

• Access to the local device (this is probably a b2g wide question)
  • file:// etc
  • loopback address/network address?

Authorization Model

• Implicit: An app will need to granted the browser permission

Implementation Requirements

• Many, TBD.