cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Chase <cha...@chromium.org>
Subject Re: Proposal for CSP support
Date Fri, 20 Feb 2015 22:12:49 GMT
Chuck,

Thanks for the feedback, it's good to know others are interested in CSP.

I've created a doc to capture the proposal in a little more detail, and
allow for more robust comments:
https://docs.google.com/document/d/1sfFs6LB1_giodyR4QwBMQssLKP_UxACZifk-VYVX2T8/edit?usp=sharing

In that doc, I've attempted to address the questions/comments both from
your email, as well as Michal's earlier response.  I'll let all interested
parties continue the conversation in the doc.

Thanks,
Jason

On 20 February 2015 at 10:54, Chuck Lantz <clantz@microsoft.com> wrote:

> 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: mmocny@google.com [mailto:mmocny@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 <chasej@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message