Yeah the <access> element is defined in the W3C widget spec like the legacy whitelist as well. Had suspected that was the case.
Rather than an "alert" if a CSP policy is not found I'd suggest a console warning - less invasive. (Not sure if you literally meant alert() or not.) I know devs pay attention to these things more than one might expect since we've received bug reports from customers about seemingly innocuous warnings from Ripple. I made some comments in the CSP doc, but one thing that it made me think about is that perhaps we need to think about/enhance this whitelist as more of a mechanism to grant access to "exec". To improve security of remote content, this would allow you to specify individual top level pages that should be allowed access to Cordova device APIs given often a good chunk of an app actually does not require device access at all. This essentially would follow suit with the idea that a different CSP policy can be applied by top level page nav. -Chuck -----Original Message----- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Tuesday, February 24, 2015 7:18 PM To: dev Subject: Re: Proposal for CSP support Reason is that the current <access> tag is used for network requests, which is what CSP is replacing. <allow-navigation> and <allow-intent> are different concepts, so there'd be no (intentional) overlap with existing <access> tags. On Tue, Feb 24, 2015 at 8:01 PM, Chuck Lantz <cla...@microsoft.com> wrote: > Yeah that was what I was hoping as well. Is there a specific reason > why we wouldn't just map the existing <access> element into the new plugin? > From what I can gather it would cover both scenarios (nav+intent). > Basically you can then have the same config.xml contents and > installing "legacy-whitelist" results in the old behavior while > "new-whitelist" (or > whatever) covers the new behavior. Certainly makes things easier for > situations where developers want to simply take an existing app and > make it more secure using CSP+new whitelist... particularly if the > legacy-whitelist gets dropped either now or sometime in the future. > > -Chuck > > -----Original Message----- > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of > Andrew Grieve > Sent: Tuesday, February 24, 2015 12:15 PM > To: dev > Subject: Re: Proposal for CSP support > > Definitely hoping that we can have all platforms use the same primitives. > Ian's intent and navigation whitelists work on Android and iOS atm I > believe. > > On Tue, Feb 24, 2015 at 1:31 PM, Chuck Lantz <cla...@microsoft.com> wrote: > > > I asked Kevin Hill from the Windows team working on the security > > model for Windows apps in Windows 10 to take a look at the document > > reference below for commentary given his experience in this area > > (including W3C involvement). He added a few comments to the doc. > > > > Andrew, is your proposal intended to be Android specific or are you > > proposing that elements like allow-navigation be introduced for iOS > > and other platforms as well? > > > > -Chuck > > > > -----Original Message----- > > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of > > Andrew Grieve > > Sent: Tuesday, February 24, 2015 7:59 AM > > To: dev > > Subject: Re: Proposal for CSP support > > > > 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_UxA > > > CZ > > > if > > > k-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 > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > >
