Compare Revisions

Application security

Change Revisions

Revision 376683:

Revision 376683 by markg on

Revision 376685:

Revision 376685 by markg on

Title:
Application security
Application security
Slug:
Mozilla/Firefox_OS/Security/Application_security
Mozilla/Firefox_OS/Security/Application_security
Content:

Revision 376683
Revision 376685
n218      There are both benefits and downsides to this approach. Then218      There are both benefits and downsides to this approach. The
> downside is that if the user interacts with the same website thr> downside is that if the user interacts with the same website thr
>ough several apps, he/she will have to log in in every app. Likew>ough several apps, he or she will have to log in in every app. Li
>ise, if a website wants to store data locally, and the user inter>kewise, if a website wants to store data locally, and the user in
>acts with this website in several apps, the data will end up gett>teracts with this website in several apps, the data will end up g
>ing duplicated in each app which could be a problem if it's a lar>etting duplicated in each app, which could be a problem if it's a
>ge amount of data.> large amount of data.
219    </p>
220    <p>219    </p>
220    <p>
221      The main benefit of this approach is that it's a more stabl221      The main benefit of this approach is that it's a more stabl
>e model. There is no way that several apps could interact with ea>e model. There is no way that several apps could interact with ea
>ch other through a 3rd party website in unexpected ways such that>ch other through a third-party website in unexpected ways such th
> installing an app causes another app to stop working. When an ap>at installing an app causes another app to stop working. When an 
>p is uninstalled there is no way that data for another app could >app is uninstalled there is no way that data for another app coul
>be lost, or that another app will stop working due to functional >d be lost, or that another app will stop working due to functiona
>dependence of the uninstalled app.>l dependence of the uninstalled app.
222    </p>
223    <p>222    </p>
223    <p>
224      There are also large security benefits. A user can safely u224      There are also large security benefits. A user can safely u
>se his AwesomeSocial app to log in to Facebook without having to >se his AwesomeSocial app to log in to Facebook without having to 
>worry that the SketchGame app can mount any types of attack for g>worry that the SketchGame app can mount any types of attack for g
>etting at the users facebook data by exploiting bugs or other sho>etting at the user's Facebook data by exploiting bugs or other sh
>rtcomings in the facebook website.>ortcomings in the Facebook website.
225    </p>
226    <p>225    </p>
226    <p>
227      There are also good privacy benefits. The user can safely i227      There are also good privacy benefits. The user can safely i
>nstall the PoliticalPartyPlus app without having to worry that Me>nstall the PoliticalPartyPlus app without having to worry that Me
>gaCorpEmployeeApp will be able to detect that the app was install>gaCorpEmployee app will be able to detect that the app was instal
>ed or what data it has created.>led or what data it has created.
n233      And just like website data is sandboxed per app, so are pern233      And just like website data is sandboxed per app, so are per
>mission grants. If App A loads a page from <a class="external fre>mission grants. If app A loads a page from <a class="external fre
>e" href="http://maps.google.com" rel="nofollow">http://maps.googl>e" href="http://maps.google.com" rel="nofollow">http://maps.googl
>e.com</a> and that page requests to use geolocation and the user >e.com</a> and that page requests to use geolocation and the user 
>says "yes, and remember this decision for all times", this only m>says "yes and remember this decision for all times," this only me
>eans that <a class="external free" href="http://maps.google.com" >ans that <a class="external free" href="http://maps.google.com" r
>rel="nofollow">http://maps.google.com</a> has access to geolocati>el="nofollow">http://maps.google.com</a> has access to geolocatio
>on within App A. If App B then opens <a class="external free" hre>n within app A. If app B then opens <a class="external free" href
>f="http://maps.google.com" rel="nofollow">http://maps.google.com<>="http://maps.google.com" rel="nofollow">http://maps.google.com</
>/a>, that page won't have access to geolocation unless the user g>a>, that page won't have access to geolocation unless the user gr
>rants that permission again.>ants that permission again for app B.
234    </p>
235    <p>234    </p>
236      And just like in the normal browser, permissions are separa235    <p>
>ted by origin. This means that if App A is granted permission to  
>use Geolocation, this does not mean that all origins running in A 
>pp A have the permission to use Geolocation. If App A opens an &l 
>t;iframe&gt; to <a class="external free" href="http://maps.google 
>.com" rel="nofollow">http://maps.google.com</a>, then <a class="e 
>xternal free" href="http://maps.google.com" rel="nofollow">http:/ 
>/maps.google.com</a> still has to ask the user for permission bef 
>ore geolocation access is granted. 
236      And just like in the normal browser, permissions are separa
 >ted by origin. This means that if app A is granted permission to 
 >use geolocation, this does not mean that all origins running in a
 >pp A have the permission to use geolocation. If app A opens an <c
 >ode>&lt;iframe&gt;</code> to <a class="external free" href="http:
 >//maps.google.com" rel="nofollow">http://maps.google.com</a>, the
 >n <a class="external free" href="http://maps.google.com" rel="nof
 >ollow">http://maps.google.com</a> still has to ask the user for p
 >ermission before geolocation access is granted.
t242      To additionally secure applications that open a large set ot242      To additionally secure applications that open a large set o
>f URLs, such as browsers, we have added a "browserContent flag". >f URLs, such as browsers, we have added a browserContent flag. Th
>The browserContent flag allows each app to have not one, but two >e browserContent flag allows each app to have not one, but two sa
>sandboxes, one for the app itself, and one for any "Web content" >ndboxes, one for the app itself, and one for any Web content that
>that it opens. For example:> it opens. For example, s<span style="line-height: 1.572;">ay tha
 >t the MyBrowser app is loaded from the</span> <a class="external 
 >free" href="https://mybrowser.com" rel="nofollow" style="line-hei
 >ght: 1.572;">https://mybrowser.com</a> <span style="line-height: 
 >1.572;">domain. This is the domain where the scripts and resource
 >s are loaded within. The scripts and resources</span> <i style="l
 >ine-height: 1.572;">belong</i> <span style="line-height: 1.572;">
 >to this domain.</span>
243    </p>
244    <p>243    </p>
245      Say that the MyBrowser app is loaded from the <a class="ext
>ernal free" href="https://mybrowser.com" rel="nofollow">https://m 
>ybrowser.com</a> domain. This is the domain where the scripts and 
> resources are loaded within. The scripts and resources <i>belong 
></i> to this domain. 
246    </p>244    <p>
245      Now, if a page in this app creates an <code>&lt;iframe mozb
 >rowser&gt;</code>, a different sandbox is created and used for th
 >is <code>&lt;iframe&gt;</code>, which is different from the sandb
 >ox used by the app. That is, if this iframe is navigated to <a cl
 >ass="external free" href="https://mybrowser.com" rel="nofollow">h
 >ttps://mybrowser.com</a>, it will result in different cookies bei
 >ng used inside the <code>&lt;iframe mozbrowser&gt;</code>. Likewi
 >se, the contents inside the <code>&lt;iframe mozbrowser&gt;</code
 >> will see different IndexedDB and localStorage databases from th
 >e ones opened by the app.
247    <p>246    </p>
248      Now, if a page in this app creates an &lt;iframe mozbrowser
>&gt; a different sandbox is created and used for this &lt;iframe& 
>gt;, which is different from the sandbox used by the app - i.e. i 
>f this iframe is navigated to <a class="external free" href="http 
>s://mybrowser.com" rel="nofollow">https://mybrowser.com</a>, it w 
>ill result in different cookies being used inside the &lt;iframe  
>mozbrowser&gt;. Likewise, the contents inside the &lt;iframe mozb 
>rowser&gt; will see different IndexedDB and localStorage database 
>s from the ones opened by the app. 
249    </p>247    <p>
250    <p>
251      This also applies if the MyBrowser app wants to create inte248      This also applies if the MyBrowser app wants to create inte
>gration with, for example, google maps, to implement location-bas>gration with, for example, Google maps, to implement location-bas
>ed browsing. If the app opens an &lt;iframe&gt; to <a class="exte>ed browsing. If the app opens an <code>&lt;iframe&gt;</code> to <
>rnal free" href="http://maps.google.com" rel="nofollow">http://ma>a class="external free" href="http://maps.google.com" rel="nofoll
>ps.google.com</a>, that will open an iframe which will receive a >ow">http://maps.google.com</a>, that will open an iframe which wi
>set of cookies for the <a class="external free" href="http://maps>ll receive a set of cookies for the <a class="external free" href
>.google.com" rel="nofollow">http://maps.google.com</a> website. I>="http://maps.google.com" rel="nofollow">http://maps.google.com</
>f the user then navigates inside Web content area, i.e. inside th>a> website. If the user then navigates inside Web content area, t
>&lt;iframe mozbrowser&gt;, to <a class="external free" href="ht>hat is, inside the <code>&lt;iframe mozbrowser&gt;</code>, to <a 
>tp://maps.google.com" rel="nofollow">http://maps.google.com</a>, >class="external free" href="http://maps.google.com" rel="nofollow
>this will use different cookies and different permissions than th>">http://maps.google.com</a>, this will use different cookies and
>e top level app.> different permissions than the top level app.
252    </p>
253    <p>249    </p>
250    <p>
254      Another example where this is useful is in a Yelp-like app.251      Another example where this is useful is in a Yelp-like app.
> Yelp has the ability to visit a restaurant's website directly in> Yelp has the ability to visit a restaurant's website directly in
> the app. By using &lt;iframe mozbrowser&gt; to open the restaura> the app. By using <code>&lt;iframe mozbrowser&gt;</code> to open
>nt website, the Yelp app ensures that the restaurant website can'> the restaurant website, the Yelp app ensures that the restaurant
>t contain an &lt;iframe&gt; pointing back to Yelp's app (which po> website can't contain an <code>&lt;iframe&gt;</code> pointing ba
>ints to <a class="external free" href="http://yelp.com" rel="nofo>ck to Yelp's app (which points to <a class="external free" href="
>llow">http://yelp.com</a>). If it does, the website will only rec>http://yelp.com" rel="nofollow">http://yelp.com</a>). If it does,
>eive the Yelp website, rather than the Yelp app. So there is no w> the website will only receive the Yelp website, rather than the 
>ay that the restaurant website can mount an attack against the ap>Yelp app. So there is no way that the restaurant website can moun
>p since the contained Yelp website won't share any permissions or>t an attack against the app since the contained Yelp website won'
> data with the Yelp app.>t share any permissions or data with the Yelp app.

Back to History