cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Proposal for CSP support
Date Wed, 25 Feb 2015 03:18:14 GMT
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 <clantz@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: agrieve@google.com [mailto:agrieve@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 <clantz@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: agrieve@google.com [mailto:agrieve@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 <chasej@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 <clantz@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: mmocny@google.com [mailto:mmocny@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 <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
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message