cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Proposal for CSP support
Date Thu, 19 Feb 2015 22:24:54 GMT
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