Security/B2G/SecurityModelv3/Origins and cookie jars
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.
Contents
- 1 Related Documentation
- 2 Potentiel threats
- 2.1 Origin
- 2.2 Cookie jars
- 2.2.1 Installing app A from appA.foo.com
- 2.2.2 A opens an iframe to example.com and the user authenticates. Then B wants to connect to the same website.
- 2.2.3 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.
- 2.2.4 A wants to load content (<script>, <link>, <img>) provided by B.
- 2.2.5 A and B share some data / B has functional dependance on A. A is deleted. What happens?
- 2.2.6 A and B store data locally. Can A track B?
- 2.2.7 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?
- 2.2.8 A does a XHR request withCredentials to B. Let's assume cookies are stored in the common jar.
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. |
current behaviour: forbidden
A | B | *threats |
web content | signed app |
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
|
signed app | web content | CSP should prevent that.
|
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