View source for Security/Reviews/B2G/mozapp

{{SecReviewInfo
|SecReview name=mozapp iframe
|SecReview 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
}}
{{SecReview
|SecReview feature goal=This is a review of the Firefox OS specifics for mozapp embedding.
}}
{{SecReviewActionStatus
|SecReview action item status=None
|Feature version=FxOS 1.0
}}
===Technical details===
<pre style="white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;">
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
</pre>
===What does a mozapp iframe do?===
<pre style="white-space:-moz-pre-wrap; white-space:-pre-wrap; white-space:-o-pre-wrap; white-space:pre-wrap; word-wrap:break-word;">
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
</pre>