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_UxACZ > > > 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 > > >
