Heh, I had a separate conversation with Ian and came to the same conclusion. Personally I think console.error may suffice, but alert is probably a good idea given the importance. Its not like it will happen to all apps, only those that install the csp plugin and forget to update their app, right?
-Michal On Tue, Feb 24, 2015 at 10:58 AM, Andrew Grieve <agri...@chromium.org> wrote: > I'm not sure allowing plugins to modify an apps security policy is a good > idea because CSP only really works when the dev understands it and puts > thought into it. > > A build step for CSP might be tricky because we don't actually know which > .html files might be navigated to (as opposed to XHR'ed for templates). It > could also be that some pages need different CSP than others. > > So, with Ian's whitelist changes > - We disallow apps from navigating, openExteral, and XHR'ing by default > - If they want the <access> behaviour back, they can install the > legacy-whitelist plugin. > > Question is, what do we want them to actually do? > Right now there's two new whitelist plugins: > - navigation-whitelist & intent-whitelist > - They look for <allow-navigation> and <allow-intent> respectively > - Neither of these actually open up all network access. > > I'd like to propose that for simplicity, we have only one "new" whitelist > plugin that: > - Does what navigation-whitelist & intent-whitelist do > - Opens up all network requests on the native side > - Has JS that runs on start-up that alert()s if no CSP meta tag is > present. > - It should recommend adding in the CSP that is used in the default > app template as a start > > This should cover 99% of use-cases (people shouldn't need to write their > own whitelist plugins), and (I hope) will be simple enough to figure out > without reading too much documentation. > > > > > On Fri, Feb 20, 2015 at 5:12 PM, Jason Chase <cha...@chromium.org> wrote: > > > 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 <cla...@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: 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 > > > > > > > > > >
