Security/B2G/SecurityModelv3/Origins and cookie jars

From MozillaWiki
< Security‎ | B2G
Jump to: navigation, search

As part of the new Security Model for v3, we don’t want to have separated cookies jars anymore for each app/website. But since we will support signed packages, we don’t want web content to be same origin with signed packaged content which will be able to access privileged APIs.

Related Documentation

https://wiki.mozilla.org/FirefoxOS/New_security_model#Origins_and_cookie_jars
https://docs.google.com/presentation/d/1SNMzMugcjXhZh1tklCUM2wM8CO9yYItGEzMe8WjEXQM/edit?pli=1#slide=id.g9b4bfe03e_1_15

Potentiel threats

Hosted signed packaged apps are privileged content. Unprivileged apps are unsigned web apps, i.e. web content.

Origin

A signed app and web content app from the same domain should not be considered same origin. bholley’s proposition is to update the origin to be declared as: {protocol, host, signatureOrNull, port}

eg: http://foo.example.com!SIGNATURE:80
The signature is empty for web content.

Cookie jars

Local data includes: cookies, localStorage data, indexedDB data, and site permissions. We’ll assume that web content uses one common cookie jar, IndexedDB, and that signed packaged apps have their own sandboxed cookie jar and storage.

Permissions should be enforced and checked per app.

Common rules:

  • Cookies are stored by default in the common cookie jar for web content.
  • if a request is performed inside a packaged app, cookies are stored in the jar specific to the app.
  • To access data stored in IndexedDB, the app's origin is checked.
Installing app A from appA.foo.com

When fetching app A for the first time, data are stored in the common cookie jar for unsigned content for the unprivileged domain appA.foo.com

cookies are stored in *threats
web content  common jar at app.foo.com
signed app common jar at app.foo.com. After checking the app is a signed package, an isolated cookie jar is created. *what kind of data are stored? this means web content could tamper with data used by the signed app while it is being installed.

The cookie jar for a signed app should be unique.


A opens an iframe to example.com and the user authenticates. Then B wants to connect to the same website.

current behaviour: the user needs to authenticate again in B

A B *threats
web content signed app B needs to authenticate on its own.
signed app web content B needs to authenticate on its own.


A wants to open an iframe embedding an URL from B or the top-level frame of A is navigated to a URL for B.

current behaviour: forbidden

A B *threats
web content signed app
  • clickjacking of signed content

apps can specify if they don't want to be framed

signed app web content ok?


A wants to load content (<script>, <link>, <img>) provided by B.
A B *threats
web content signed app enabling CORS for signed package
  • where do we stored CORS headers? see below
signed app web content CSP should prevent that.
  • arbitrary code execution in signed content


A and B share some data / B has functional dependance on A. A is deleted. What happens?
A B *threats
web content signed app ok if data were replicated in both cookie jars
signed app web content ok if data were replicated in both cookie jars.


A and B store data locally. Can A track B?
A B *threats
web content signed app no
signed app web content no


A and B are from the same domain foo.com: appA.foo.com and appB.foo.com. Can A overwrite cookies of B if cookies have for scope foo.com?
A B *threats
web content signed app no, since apps shouldn’t be considered same origin and have separate cookie jars.
signed app web content no, since apps shouldn’t be considered same origin and have separate cookie jars.


A does a XHR request withCredentials to B. Let's assume cookies are stored in the common jar.
A B *threats
web content signed app
signed app web content cookies are public to web content

See issues at https://wiki.mozilla.org/FirefoxOS/New_security_model#Origins_and_cookie_jars: “Do requests from a signed package to unsigned content use the package's cookie jar? Or the normal cookie jar. I.e. if a signed package does an XHR request to a normal website, does that use the website's cookies?

Does this mean that the *cookies* used for signed content is the same as the cookies used for unsigned content? I.e. that only IDB/localStorage/permissions are separate for signed content. That seems to be the case if network requests to normal websites from signed content uses the normal cookie jar. What does document.cookies return? Should we make it return null?”


Differences between regular apps and websites:

  • the Chrome UI will be removed when displaying web content/apps on FxOS