Content Security Policy for Gaia Apps

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Content Security Policy for Gaia Apps

Paul Theriault
(CCing dev-security for added security input, but please reply to
[hidden email])

As part of the Open Web App Security Model
(https://wiki.mozilla.org/Apps/Security), a strict content security
policy is proposed for Certified applications. It is expected that all
Gaia apps will fall into the certified category, 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?)

*Inline Event handlers (onclick, onmessage etc) are also disabled by
this CSP. From a quick skim, only the dialer uses these, so it will need
to be modified to use addEventListener instead.

* 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)

Why are we proposing to enforce this?
=========================
The main control provided by this feature is a mitigation of a class of
cross-site scripting attacks. Also certified apps is code are verified
through our secure development processes, and we trust this code is
(relatively) free of security vulnerabilities. Allowing Apps to load
potentially insecure code dynamically that has access to the same
elevated permissions would break this model.

Thoughts, comments, suggestions?

-Paul







_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Content Security Policy for Gaia Apps

Ben Francis-7
On Wed, Jun 6, 2012 at 9:23 AM, Paul Theriault <[hidden email]>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?


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

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


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

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.

Ben

--
Ben Francis
http://tola.me.uk
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Content Security Policy for Gaia Apps

Ben Francis-7
On Thu, Jun 7, 2012 at 12:32 PM, Ben Francis <[hidden email]> wrote:

> storing favicons in the browser app won't work at all if the same-origin
> policy applies to XHR.
>
>
It turns out that the homescreen has the same issue with app icons
https://github.com/mozilla-b2g/gaia/issues/1603

--
Ben Francis
http://tola.me.uk
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Content Security Policy for Gaia Apps

Paul Theriault
In reply to this post by Ben Francis-7

On Jun 7, 2012, at 9:32 PM, Ben Francis wrote:

> On Wed, Jun 6, 2012 at 9:23 AM, Paul Theriault <[hidden email]> 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Content Security Policy for Gaia Apps

Lucas Adamski-2
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 <[hidden email]> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: Content Security Policy for Gaia Apps

JOSE MANUEL CANTERA FONSECA
El 27/06/12 19:08, "Lucas Adamski" <[hidden email]> 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
>>><[hidden email]> 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
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-security
>
>_______________________________________________
>dev-gaia mailing list
>[hidden email]
>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
[hidden email]
https://lists.mozilla.org/listinfo/dev-security