Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAEeF2Tc1=zQiKFawnPyfRoTao4c4BAibJiuR=jSp2HLFoVtLYw@mail.gmail.com>
References: 
 <CAMi8Y5WLk1-M0=tq2rSG8Y07ffihrQK3YR0cfjf6qw=F=1Gb=w@mail.gmail.com>
 <CAEeF2TdeOQ60_2FdmxCXhkKn1xXWsQEaHiHSAj_jfWdrQUpSbg@mail.gmail.com>
 <BY2PR03MB0761C1689DA2035134EA938CF2A0@BY2PR03MB076.namprd03.prod.outlook.com>
 <CAMi8Y5VuetpP4rd4TxAnrof9j652j9RH_viXoAbr0PMvzbTPUA@mail.gmail.com>
 <CABiQX1W2-zQMee49Dk5oTbu-qQrc_bvrbOxOa5n7G0raBNf-hA@mail.gmail.com>
 <CAEeF2Tc1=zQiKFawnPyfRoTao4c4BAibJiuR=jSp2HLFoVtLYw@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Tue, 24 Feb 2015 12:50:12 -0500
Message-ID: 
 <CABiQX1U-n12fyqqhgOnSbAUiQfmLJwcpGmAVT8MCxyY+HncPLw@mail.gmail.com>
Subject: Re: Proposal for CSP support
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec519691fc6b986050fd9270f

--bcaec519691fc6b986050fd9270f
Content-Type: text/plain; charset=UTF-8

problem with console.error is that you generally don't see start-up logs
for iOS.

On Tue, Feb 24, 2015 at 11:25 AM, Michal Mocny <mmocny@chromium.org> wrote:

> 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 <agrieve@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 <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_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 <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
> > > > >
> > > >
> > >
> >
>

--bcaec519691fc6b986050fd9270f--