El 27/06/12 19:08, "Lucas Adamski" <ladam...@mozilla.com> escribió:

>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.

The same happens in the Contact App. How this issue is going to be
overcome?

>
>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_his
>tory.js#L89
>
>Save object containing this blob to IndexedDB
>https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/global_his
>tory.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
>>><ptheria...@mozilla.com> 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.ht
>>>ml#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/w
>>>indow_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
>> dev-security@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security
>
>_______________________________________________
>dev-gaia mailing list
>dev-g...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-gaia
>



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to