Security/Reviews/B2G/mozapp

From MozillaWiki
< Security‎ | Reviews‎ | B2G
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed

mozapp iframe
Target https://bugzilla.mozilla.org/show_bug.cgi?id=751026

See also https://bugzilla.mozilla.org/show_bug.cgi?id=750996

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


Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

This is a review of the Firefox OS specifics for mozapp embedding.

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

`

Threat Brainstorming

'


Action Items

Action Item Status None
Release Target FxOS 1.0
Action Items
'

Technical details

A non-standard attribute was added to the iframe tag called
mozapp [1] This attribute allows a webpage to specify a manifest URL, that was previously pre-installed on the device or installed through window.navigator.mozApps.install [2]. A valid manifest meets the requirements set forth at [3] and may grant an app more privileges than a normal webpage has.

A mozapp iframe must also have the mozbrowser attribute set. This is currently a limitation in the design of the feature and may be removed in the future. [4] 

This means that an embed mozapp iframe will have mozbrowser capabilities. [5] This is only relevant to the embeddor or the mozapp iframe, since it will be able to listen for certain events. Currently mozapp iframes are embedded by the System app which is fully trusted.  

Embedding a mozapp iframe requires the "embed-apps" permissions which is only given to certified apps. [6][7]

Suffice to say, a user submitted app will never be able to create mozapp iframes under the current model. 

[1] - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
[2] - https://developer.mozilla.org/en-US/docs/Web/API/Apps.install
[3] - https://developer.mozilla.org/en-US/docs/Web/Apps/Manifest
[4] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l381
[5] - https://developer.mozilla.org/en-US/docs/WebAPI/Browser
[6] - http://hg.mozilla.org/mozilla-central/file/70cfbdceb63a/content/html/content/src/nsGenericHTMLFrameElement.cpp#l393
[7] - http://hg.mozilla.org/mozilla-central/file/dd2ffe93fb2f/dom/apps/src/PermissionsTable.jsm#l208

What does a mozapp iframe do?

A mozapp iframe with a valid manifestURL and embeddor with proper permissions is granted the enhanced functionality of webapps. Permissions granted / denied are set when the app is installed. The biggest difference is the "origin" used when performing same origin checks. The gecko core was modified to use the concept of an extended origin defined as
aExtendedOrigin = appId + "+" + { 't', 'f' } "+" + origin [1]

appId: This is the appId for the supplied manifest, otherwise it is either NO_APP_ID or UNKNOWN_APP_ID [3]
{'t', 'f,'}: This corresponds to whether this origin exists inside a mozBrowserFrame or not
origin: This is the origin of the page / document. Note that the scheme will be app:// for packaged app resources

This triple uniquely identifies the origin for cookies, session/localstorage and cross-origin checks. A mozapp iframe that is browsed to www.mozilla.org does not necessarily have the access to the cookies from a browser visiting www.mozilla.org . This can be due to the appIds being different and / or InMozBrowserFrame being different.


[1] - http://hg.mozilla.org/mozilla-central/file/f83604cff118/caps/src/nsScriptSecurityManager.cpp#l2887
[2] - http://hg.mozilla.org/mozilla-central/file/f83604cff118/caps/idl/nsIScriptSecurityManager.idl#l228