Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of iclelland@google.com designates
 209.85.218.45 as permitted sender)
MIME-Version: 1.0
References: 
 <CAK_TSXL69eQKaZ9p4dRy_e1JWktf9Jv8WKRYmJg_oQEa7=LMvQ@mail.gmail.com>
 <CAEeF2TcZcbzM6VAUS8w1SwW765CtVycdP2BoArmURXnTj54HTA@mail.gmail.com>
 <CAK_TSXKjC1w-FNK_Tt4EbKikqFoXRN5Rp8Y5R8DYPkMVQ78s_A@mail.gmail.com>
 <BLUPR03MB065C77D91E0AC6004B3077FCF6F0@BLUPR03MB065.namprd03.prod.outlook.com>
 <CAK_TSXLWa8m0NdSFuPKigbUUouEqu2YaxkBptdLS2WBbHH52uA@mail.gmail.com>
 <BLUPR03MB065DE7FD19A3762F5E3122BCF6C0@BLUPR03MB065.namprd03.prod.outlook.com>
 <CABiQX1WNY8CCb=_2M4-2GNyGadM+mVaL795FYdpEtag0Yo1ujw@mail.gmail.com>
 <BLUPR03MB06572CAC012F1AD8A0AA03BCF6D0@BLUPR03MB065.namprd03.prod.outlook.com>
From: Ian Clelland <iclelland@chromium.org>
Date: Wed, 17 Dec 2014 16:16:12 +0000
Message-ID: 
 <CAK_TSX+8DxKDdsZ45RdP3L1pYgjqcmuXHbsPQRktkALO7oj72g@mail.gmail.com>
Subject: Re: How to handle CSP for XHR in Cordova 4.0
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=001a113d12ec5635ec050a6bcb95

--001a113d12ec5635ec050a6bcb95
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Definitely want to handle iOS, with the same policy. I've been working on
that in parallel with Android.

Do we want to use <access> for Nav? I wasn't sure, given its history, and
the fact that we're changing its behaviour. Is it better to stick with the
familiar tag and change what it tries to do? Or create a new tag and
deprecate <access>?

On Wed Dec 17 2014 at 10:30:18 AM Chuck Lantz <clantz@microsoft.com> wrote:

> What about top level nav and script access?  Would the thought be that th=
e
> <access> elements would map to that in the base platform?  I'm thinking i=
n
> terms of consistency across the different platforms.  It strikes me we'd
> want to update iOS at least as well.
>
> -Chuck
>
> -----Original Message-----
> From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew
> Grieve
> Sent: Tuesday, December 16, 2014 7:21 AM
> To: dev
> Subject: Re: How to handle CSP for XHR in Cordova 4.0
>
> On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz <clantz@microsoft.com> wrote=
:
> >
> > Near term, for Windows 8.0/8.1, a custom security policy is in place
> > at the platform level for store apps so CSP doesn't really apply there
> > at the moment. (And, to be really specific, CSP support is pretty
> > limited in
> > IE10/11 focusing on the sandbox directive. The Windows 10 Tech Preview
> > is where you can see the real support in IE right now.) So, it's a
> > more of forward-thinking topic in that world.
> >
> > A related question, however - CSP support only started in the Android
> > browser with 4.4 did it not? Obviously Crosswalk would have it but
> > what about when using the base browser?  Is the thought devs should
> > use the old whitelist model here?
> >
>
> I think one of the big issues is that the whitelist never worked for
> blocking *all* requests. It didn't work pre-3.0, and it doesn't block
> <audio>, <video>, websocket in any version. Supporting the illusion of a
> whitelist is probably worse than not supporting it at all.
>
>
>
> >
> > Safari seems to support it back at least as far as iOS 7 (or 6 with a
> > custom header) - the main reason I bring it up is developers could see
> > different behaviors between devices and versions if the default CSP
> > policy leaves something like inline or eval disabled.
> >
> > -Chuck
> >
> > -----Original Message-----
> > From: Ian Clelland [mailto:iclelland@chromium.org]
> > Sent: Monday, December 15, 2014 11:17 AM
> > To: dev@cordova.apache.org
> > Subject: Re: How to handle CSP for XHR in Cordova 4.0
> >
> > On Mon Dec 15 2014 at 11:28:43 AM Chuck Lantz <clantz@microsoft.com>
> > wrote:
> >
> > > For the Windows platform, IE 10 and 11 support CSP 1.0 - there's one
> > > subtle difference (X-Content-Security-Policy vs
> > > Content-Security-Policy in the HTTP header).  The Win 10 Tech
> > > Preview
> > already has full CSP support.
> > > In general, the conventional wisdom is to push app models towards
> > > the CSP and away from custom enforcement policies from our point of
> view.
> > > I love the idea of Cordova heading this same direction.
> > >
> >
> > That's great to hear.
> >
> > >
> > > Windows apps have a URI whitelist focused on top level navigation
> > > and JavaScript includes on pages not XHR. The main reason to lock
> > > down at this level is to reduce the risk of a malicious user
> > > navigating the page to a URI outside of the app author's control and
> > > take advantage of sensitive APIs.  So, I think some level of
> > > whitelist to help out in this situation is advisable even with CSP
> > > being used. We=E2=80=99ve mapped <access> elements in config.xml to t=
he top
> > > level nav whitelist for this reason. CSP isn=E2=80=99t really designe=
d to help
> with this kind of problem.
> > >
> >
> > Agreed. CSP on the web can't really control navigation, or else web
> > page authors would be able to trap browser windows on their sites. It
> > makes sense for installed apps, but not so much for sites or web apps.
> >
> >
> > >
> > > Perhaps a default CSP policy in the template coupled with a top
> > > level nav whitelist is the right starting point.
> >
> >
> > That sounds like what I'm trying to implement on Android and iOS. Let
> > me know what I can do to make that easy for Windows.
> >
> >
> > > Determining what the CSP policy looks like will be really important
> > > =E2=80=93 by default CSP blocks both inline and eval use. Of the two,=
 inline
> > > use tends to be the bigger risk factor.
> > >
> >
> > True -- eval without inline can theoretically be controlled, although
> > it's not great practice. inline, with or without eval is an XSS
> > waiting to happen, in a web app.
> >
> >
> > >
> > > -Chuck
> > >
> > > -----Original Message-----
> > > From: Ian Clelland [mailto:iclelland@google.com]
> > > Sent: Friday, December 12, 2014 9:34 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: How to handle CSP for XHR in Cordova 4.0
> > >
> > > Default CSP is a good idea. I was worried about leaving new apps
> > > vulnerable by default but that should close that.
> > >
> > > Do we know what the CSP story is on all platforms, to know that it
> > > won't break anything else?
> > > On 12 Dec 2014 11:56, "Michal Mocny" <mmocny@chromium.org> wrote:
> > >
> > > > I'm fine with 1. coupled with a default CSP in the template
> > application.
> > > >
> > > > For older apps not written from scratch, we can perhaps strongly
> > > > suggest installing the legacy-whitelist, which would change the
> > > > default-open behaviour to default-closed.
> > > >
> > > > Together, that would give sensible defaults that aren't
> > > open-to-everything?
> > > >
> > > > -Michal
> > > >
> > > > On Fri, Dec 12, 2014 at 9:13 AM, Ian Clelland
> > > > <iclelland@chromium.org>
> > > > wrote:
> > > >
> > > > > I'm just building the new optional whitelist plugins for Cordova
> > > > > Android and iOS 4.x, and I'm thinking about how to encourage
> > > > > developers to use
> > > > CSP
> > > > > for network requests, as opposed to a
> > > > > Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve.
> > > > >
> > > > > (Note: This is really just about things like XHR requests, <img>
> > > > > and <script> tags, etc, which are historically the only things
> > > > > that we've reliably been able to filter out. Other classes of
> > > > > network requests just bypass all of our code anyway, which
> > > > > sucks, and frame navigation and external application launches
> > > > > are already well handled
> > > by the framework).
> > > > >
> > > > > The policy I've implemented on the unplug-whitelist branches,
> > > > > which at first thought at least *sounds* sane, is that network
> > > > > requests are
> > > > blocked
> > > > > by default. (At least all of the ones that we can intercept).
> > > > > That way, a plugin, such as the legacy-whitelist plugin, can
> > > > > open up access to
> > > > specific
> > > > > resources, and the fallback is safety.
> > > > >
> > > > > To use CSP, though, we have to open up access to the outside,
> > > > > and we
> > > > don't
> > > > > necessarily know what the developer wants to open (the whole
> > > > > point is
> > > > that
> > > > > they specify in the HTML, not in a config file.) The easiest way
> > > > > is to
> > > > open
> > > > > up access to *all* resources to the webview, and then restrict
> > > > > it through the CSP header/meta-tag, which does a better job of
> > > > > blocking those
> > > > requests
> > > > > than we do in any case.
> > > > >
> > > > > I think that we want to encourage developers to use CSP, for a
> > > > > lot of reasons, but I'm going to have to do one of these things,
> > > > > and I'm not entirely sure which is the right one:
> > > > >
> > > > > 1. Open access to all network resources by default in Cordova 4.x=
.
> > > > >   * This doesn't apply to navigations, or launching other apps.
> > > > > They're still blocked by default.
> > > > >   * Any plugin implementing shouldAllowRequest would still be
> > > > > able to
> > > > turn
> > > > > this into a disallow-by-default whitelist
> > > > >   * We can't block everything anyway (see websockets,
> > > > > audio/video
> > > > streams /
> > > > > probably more), so it removes the illusion that we can.
> > > > >
> > > > > 2. Make another whitelist-y plugin, something like
> > > > "org.apache.cordova.csp"
> > > > > that exists only to open up access to network resources. Direct
> > > > > all users who want to use CSP to install that plugin first
> > > > >   * It's a 4th network plugin (after legacy-whitelist,
> > > > navigation-whitelist
> > > > > and intent-whitelist)
> > > > >   * Adding it doesn't actually add any CSP protection, so it
> > > > > probably
> > > > needs
> > > > > a better name
> > > > >   * It's an extra step that may confuse people and limit
> > > > > adoption
> > > > >
> > > > > 3. Do something crazy. Maybe a CSP plugin that automatically
> > > > > creates CSP tags *and* updates the XHR whitelist, both from
> > > > > config
> > directives.
> > > > >   * Lots more work
> > > > >   * We probably don't know enough about real requirements to get
> > > > > this
> > > > right
> > > > >   * If CSP is doing its job, then the XHR whitelist isn't needed
> > > > > anyway;
> > > > it
> > > > > would just be another layer that isn't doing anything different.
> > > > >
> > > > > I'm leaning towards #1, but its a it's a decision that we really
> > > > > should think about and decide on-list before moving forward.
> > > > >
> > > > > Ian
> > > > >
> > > >
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
>

--001a113d12ec5635ec050a6bcb95--