FirefoxOS/New security model: Difference between revisions

FirefoxOS/New security model (view source)

Revision as of 23:27, 29 July 2015

445 bytes added , 29 July 2015

Document the OriginAttributes solution

Sicking

Confirmed users

716

edits

@@ Line 104: / Line 104: @@
 === Origins and cookie jars - {{Bug|1153435}} ===
-The biggest change here is that we should stop always using different cookie jars for different apps. In particular normal unsigned content should always use the same cookie jar no matter which app it belongs to.
+The biggest change here is that we should stop always using different cookie jars for different apps. In particular normal unsigned content should always use the same cookie jar no matter where it was loaded.
-However signed packages will get their own cookie jars. So a signed package will not share cookies, IndexedDB data, etc with unsigned content from the same domain. It will also not share data with other signed packages from the same domain. This is to ensure that unsigned content from the same domain can't read for example sensitive data that the signed content has cached in IndexedDB.
+However signed packages will get their own cookies and IndexedDB data. Content inside a signed package will not share cookies, IndexedDB data, etc with unsigned content from the same domain. It will also not share data with content from other signed packages from the same domain. This is to ensure that unsigned content from the same domain can't read for example sensitive data that the signed content has cached in IndexedDB. And to prevent unsigned content from writing into the localStorage that signed content uses and thereby tricking the signed content into performing unintended actions.
-♦ '''Issue:''' 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?
+However when pages from inside a signed package makes network requests to other websites, it should still use the normal cookies from those websites. And if a page from a signed package creates an <iframe> containing an insigned website, then that website will be loaded with its normal cookies and will have access to its normal IndexedDB data.
-♦ '''Issue:''' Figure out how to give signed content its own cookie jar. One potential solution here is to remove our close tie between cookie jar and appid. Another possible solution would be to make the various APIs use the full package path instead of the domain as key.
+In other words, each signed package acts like a separate website. They do not act like a separate "world"/"context".
-However when we are loading the package itself, we don't use the cookie jar of the signed app. Instead we use the cookie jar of the unsigned content for the origin which the package lives un. We have to do it this way since when we fetch a signed package the first time, we don't know that the package is signed, and so we use the normal cookie jar for that domain.
+The way that we will implement this is by generalizing the current <tt>appId</tt> and <tt>isInBrowserElement</tt> mechanism. We will introduce a <tt>OriginAttributes</tt> struct which will hold the "cookie jar" that is used for a given web page. We can then write policies for which parts of this struct is inherited into iframes, and which parts do not. The nsIPrincipal interface will contain one of these structs. We will also have functions for serializing this struct to a string, and for parsing such a string back into a struct.
-♦ '''Issue:''' What happens if unsigned content does an XHR request to a URL inside a signed package. There doesn't seem to be any security issues involved in allowing that.
+Most code will treat this OriginAttributes struct as an opaque value. When we store data we store as part of the key the serialization of the OriginAttributes.
-♦ '''Issue:''' 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?
+Two pages will only be considered same-origin if they have the same scheme+host+port, but also if all of the values inside the OriginAttributes of their nsIPrincipal have the exact same values.
-♦ '''Issue:''' One potential solution here is to do security checks in the parent only to protect the storage data and permissions of the signed content. And make sure to flag the principals used for documents loaded from signed packages as belonging to the appropriate package. But for anything related to network, just treat signed content like normal content belonging to the normal cookie jar.
+We will then add a 'signedPkg' member to OriginAttributes. When a page is loaded from inside a signed package, we will read a package-identifier from inside the package and set it in the OriginAttributes of the nsIPrincipal of the page.
-♦ '''Issue:''' Would it be simpler to make signed content use an entirely separate cookie jar. Including for XHR requests and <iframe>s to content outside of the signed package? That might allow us to use a more generic cookie jar feature.
+However, when we do the network request for the package itself, this is treated like other network requests to the webserver. I.e. the network request is considered as an unsigned request and so the normal cookies of the webserver is sent. We have to do it this way since when we fetch a signed package the first time, we don't know that the package is signed, and so we use the normal cookie jar for that domain.
-Signed content must never be considered same-origin with unsigned content, or content from another signed package. This is to ensure that unsigned content from the same https domain can't open the signed content in an <iframe> and then reach in to the opened page and use its privileges.
+The effect of this is that when we are making network requests, these are never affected by package signing. As mentioned above, requests for the package itself are not affected, and requests for pages inside the package don't send any cookies at all since they are simply loaded from the package.
-The mechanism which is used to ensure that signed packages get a unique cookie jar should also be used to make sure that principals from signed and unsigned pages are never considered same-origin.
+However, when a page from a signed package access the document.cookies API, the cookies returned *do* use the full OriginAttributes. I.e. the document.cookies API is treated like other storage APIs like IndexedDB and localStorage.
-♦ '''Issue:''' Figure out exactly what field to use to indicate which signed package a principal belongs to.
+♦ '''Issue:''' Verify with Honza that this is is doable and not complex. It should hopefully be the most natural way to write the cookie code.
+If any page does a XHR request to a URL inside a signed package this is treated like any other network request and is permitted. This doesn't expose any user-private information and simply returns content that resides on the server.
 == Implementation ==