I filed bug https://bugzilla.mozilla.org/show_bug.cgi?id=768029 to track this. To be clear we are being more selective in the policy being applied; we want to only restrict importing of code and CSS (including objects), which requires also preventing inline script. As Ben pointed out (and reiterated in person), the biggest issue with this approach is that it prevents the very common pattern of storing images as object blobs and loading them as data URIs.
a) loading data URIs as XHR source b) loading object blobs as images Here is a list of examples Ben just provided (I'd rely on these over my description above): Get favicon as blob over XHR (where the favicon URL can be an HTTP URL or a data URL) https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/global_history.js#L89 Save object containing this blob to IndexedDB https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/global_history.js#L328 Create object URL from blob read back from IndexedDB https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/browser.js#L399 Set object URL as background image of HTML element https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/browser.js#L400 Thanks, Lucas. On Jun 8, 2012, at 1:30 AM, ptheriault wrote: > > On Jun 7, 2012, at 9:32 PM, Ben Francis wrote: > >> On Wed, Jun 6, 2012 at 9:23 AM, Paul Theriault <[email protected]> >> wrote: >> It is expected that all Gaia apps will fall into the certified category >> >> Really?! If all Gaia apps are considered to require enough privileges to >> need the "certified" level, given that "3rd party certified apps" are "out >> of scope for 1.0" >> (https://wiki.mozilla.org/Apps/Security#Out_of_scope_for_1.0), does that >> mean that third party developers won't be able to write apps which are able >> to compete with any of the Gaia apps and users will be stuck with the ones >> that ship with the device? > > I think this is more a discussion of what permission we restrict to certified > apps, (as opposed to trusted) rather than a discussion of CSP. The point of > this proposal is that I would like to see CSP applied for all Gaia apps as a > significant security control. I think we still need to have the final "which > permissions are available to which apps" but I'll keep that separate if > that's ok. > > >> >> , and as such I wanted to raise this requirement for discussion, as there >> are significant implications which have not really been explored as yet. >> >> Proposal >> ========================= >> The proposed requirement is that all certified apps have a strict CSP >> (default-src 'self') which allows loading of resources from same-origin >> only. I had a skim over the Gaia apps and the key impacts I see are: >> >> * For <script> tags, this means that all script must be contained in files >> loaded from the same origin. This is generally already the case for most >> Gaia apps, but there are a few inline script tags in some apps (e.g. >> https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/index.html#L8 >> - though this looks like a fix until the webapi.js is in the browser >> itself?) >> >> Applying same-origin to JavaScript, CSS and appcache will mean that no >> assets (JavaScript libraries, CSS files or even icons) can be shared between >> Gaia apps. > > They could be on a parent domain though right? We could whitelist a shared > origin in CSP if this was necessary, but it would be more elegant if it was > same origin I think. Wouldn't they have to be same origin anyways since > app-cache enforces same origin? > >> It will be more difficult to maintain duplicate code but we can probably >> live with this if necessary. Appcache actually already has a same-origin >> policy when assets are loaded over HTTPS, at least that's what the spec says >> even if browsers don't always implement it that way… > > (What does Firefox enforce ? - mdn says that absolute URLs in an app cache > manifest must be same origin > https://developer.mozilla.org/en/Using_Application_Cache) >> >> "Whitelisting a specific domain for gaia apps" as suggested below is another >> thing that we can do for gaia apps but third party developers can't do for >> their apps. Doesn't sound like a very level playing field. > > Well I was actually thinking that apps would be able to specify the CSP in > their manifest - that is what Chrome does for Extensions. This could be a > security hole, but it could be reviewed as part of the review process for > trusted and certified apps. > >> >> >> * data URIs are blocked. Again these arent really used much but there are a >> few examples (e.g. >> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/windows/window_manager.js#L380) >> >> This could break stuff. For example, in the browser app favicons can >> actually be data URIs. Having said that, storing favicons in the browser app >> won't work at all if the same-origin policy applies to XHR. >> >> This seems to be the complete opposite direction to >> https://bugzilla.mozilla.org/show_bug.cgi?id=692677 which looks to relax the >> same-origin restriction for XHR for privileged apps to allow not only little >> things like favicons in browsers, but also entire apps like client-side news >> readers, podcast clients and calendar apps. > > This did occur to me after Adrienne's comment. We will need to allow > exceptions, in this case for the connect-src attribute. If we find more > exceptions that the rule, then maybe we have to think about relaxing the CSP, > but I would prefer to default to strict and allow by exception. >> >> If lots of apps will be forced to be certified (which I hope they won't), >> they are very likely to need a way to request exceptions to these >> restrictions. > > Definitely agree. > >> >> Ben >> >> -- >> Ben Francis >> http://tola.me.uk > > _______________________________________________ > dev-security mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
