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 >
