Hey Jason - Glad to see this proposal!  A number of us at Microsoft have been 
talking along these same lines actually. Windows 10 apps will include CSP 
support as the latest version of IE has support so I'd say we're completely in 
support of moving Cordova apps down this path.  In fact I'd want to make sure 
that any CSP related metadata tag injection also applied to the Windows 
platform as well.  

A few of thoughts:

1. I definitely know there is quite a bit of interest still in being able to 
enable hosted (https accessed and controlled by the developer) app content 
access Cordova device APIs (which is currently a shortcoming of Windows 8.0/8.1 
apps so we hear about it quite a bit).  As a result, we'll want to be sure 
Cordova doesn't inhibit this use case at a base level.  That said, having a 
default CSP policy that restricts hosted in the template is fine and would 
promote secure practices since you need to exercise caution when mixing in any 
remote content even when you control it completely.  Also agree with inline 
being high risk.

2. Re: Long term, one thing that CSP doesn't cover well is which URIs should be 
granted elevated device access. Given hosted content with plugin device API 
access is still a scenario we'll need to consider, perhaps we should consider 
using the config.xml <access> element to represent URIs that have device API 
access (beyond standard browser access).  Otherwise we get into a bit of an 
"all or nothing" situation as it pertains to hosted app content which poses a 
larger security risk if you opt to extend device API access beyond local 
content. (It also strikes me this is a general gap in the web standard as a 
whole.)

3. Eval is actually a bit tougher - I know when we've look at this in the past 
it impacted JS frameworks far more than inline did.  (Ex: With Angular you can 
stop using eval but you take a perf hit which is a bigger deal on mobile than 
desktop.)  Definitely the most secure practice - but it also could cause the 
default template to appear to "not work."  If we omit the "unsafe-eval" 
directive in the CSP policy in the template we'll want to be crystal clear on 
how to alter it.  That could be solved with proper documentation and blog posts 
though.

4. I'd suggest we also consider the new "browser" platform here since 
Chrome/Firefox/IE (as of Win 10) have support. Should be "free", but I'm 
guessing the metadata tag injection you mention is something we could probably 
just do all-up rather than only for specific platforms.

-Chuck

-----Original Message-----
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Thursday, February 19, 2015 2:25 PM
To: dev
Subject: Re: Proposal for CSP support

Thanks for this clear outline.

Jason, I know you've been working on the short-term items for a while as part 
of your investigation, fixing things as you went -- what is the current state 
of CSP support in platforms / plugins?  What portion already has fixes (or PR 
for them), what work is known but undone, and what hasn't been investigated 
much at all?

-Michal

On Thu, Feb 19, 2015 at 4:55 PM, Jason Chase <cha...@chromium.org> wrote:

> I'm interested in full-blown support for CSP (Content Security Policy) 
> in Cordova.  While we're close to having new and improved whitelist 
> functionality, there are gaps in what the whitelist is able to protect 
> against. In particular, inline script and eval() are higher risks that 
> are not addressed by whitelists.
>
> Many Cordova apps may use only static content, or not include any 
> third-party content.  However, there are certainly examples of apps 
> that need to include user input/third-party content, mixed with the 
> app's own HTML content.  In some cases, platforms may even restrict 
> functionality (see [1]). I think CSP is a compelling answer for these 
> scenarios, and for security in general for apps.
>
> Assuming CSP support is valuable, the question is how to implement?
> Support for CSP is not universal across platforms.  It is known to be 
> supported on Android (KitKat and later), iOS (since 7.1), and Firefox.
> Where supported, it is typically via a HTTP response header, or a META 
> tag in the document.
>
> I've done some investigation into feasible approaches.  As a result, 
> I'm proposing as below.
>
> Long term goal:
> Cordova supports CSP in apps *and* plugins, and is enabled/secure by 
> default.  Ideally, CSP rules can be configurable and automatically 
> applied to all content (i.e. so developers can fall into the pit of 
> success)
>
> Achieving this goal will likely require incremental progress over a 
> number of releases.  At a high level, first make changes so developers 
> can manually apply CSP to their apps.  Longer term, add support for 
> configurability and automatic application of CSP.
>
> Short term plan:
> - Change new app template to contain CSP meta tag with a default, 
> secure policy (i.e. no inline script, eval(), only local app content)
> - Remove any blockers to default policy from framework and core plugins.
> This would be a continuation of the work in CB-8210, applied to other 
> platforms.  For example, this would fix any framework code that relies 
> on sending javascript to be executed inline, from the native side
> - Deprecate any framework APIs that allow less secure practices.  Many 
> already are marked as deprecated (at least on Android)
> - Update docs/samples to include CSP, and clearly state that use of 
> inline javascript is deprecated
>
> Long term plan:
> - In a future major release, remove the previously deprecated 
> framework APIs
> - Define/implement a configuration model for CSP rules
> - Implement a build/package step to apply configured CSP rules to all 
> content as meta tags.  Run-time support involves re-writing content, 
> and/or intercepting resource requests.  The feasibility of 
> intercepting requests is highly variable across platforms, at greater 
> cost/complexity than build-time.
>
> I'm very interested in any comments on this proposal.  This includes 
> questions around use cases (missing or otherwise), different 
> requirements, technical concerns, .etc.
>
> Thanks,
> Jason
> Google Cordova Team
>
> [1] http://callback.markmail.org/thread/yxmmya2o2lc26tpi
>

Reply via email to