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 iclelland@google.com
 designates 209.85.218.53 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>
 <CAK_TSX+8DxKDdsZ45RdP3L1pYgjqcmuXHbsPQRktkALO7oj72g@mail.gmail.com>
 <BLUPR03MB06538F6A62120AAC03C2D1DCF6D0@BLUPR03MB065.namprd03.prod.outlook.com>
 <CAK_TSXKhBoFQFvPsttbgRV8-pwVhbosuVu-d7ck-E5JmW3GuPA@mail.gmail.com>
 <BLUPR03MB065435870A37E9B2F4AF7B4CF6D0@BLUPR03MB065.namprd03.prod.outlook.com>
 <CABiQX1UFn5S_cxvwT7fOWXS6Zjd=BAWZt8OFi+Si3p4FLLr51w@mail.gmail.com>
From: Ian Clelland <iclelland@chromium.org>
Date: Fri, 19 Dec 2014 13:33:50 +0000
Message-ID: 
 <CAK_TSX+fOabPcn99+CAmq1yhBczHw1sd0e2T=d4LahWydNNR_A@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=001a11c2de6462e4a8050a91c223

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

On Thu Dec 18 2014 at 9:42:18 AM Andrew Grieve <agrieve@chromium.org> wrote=
:

> That's a good point Chuck. Since the meaning of <access> would be changin=
g
> in a dramatic way, I think we should just come up with something new, and
> leave <access> for anyone that wants to use the legacy-whitelist plugin.
>
> Maybe:
> <allow-navigation>PATTERN</allow-navigation>
> <allow-system-url>PATTERN</allow-system-url>
>
> On Wed, Dec 17, 2014 at 5:29 PM, Chuck Lantz <clantz@microsoft.com> wrote=
:
> >
> > Yeah, I also am thinking about "upgrade" situations where someone takes
> an
> > existing app and moves it to Android Cordova 4.0. It strikes me there
> we'd
> > either want the existing behavior to be preserved (flaws aside) or move
> it
> > to the top level nav behavior.  Did I read correctly the current
> whitelist
> > would be refactored out to a plugin?
>

And yes, the current whitelist, flaws and all, is refactored out into
org.apache.cordova.legacy-whitelist. The source is in the cordova-plugins
repo; it hasn't been published yet.

Ian


> >
> > -Chuck
> >
> > -----Original Message-----
> > From: Ian Clelland [mailto:iclelland@chromium.org]
> > Sent: Wednesday, December 17, 2014 1:02 PM
> > To: dev@cordova.apache.org
> > Subject: Re: How to handle CSP for XHR in Cordova 4.0
> >
> > I think that access tags (and the widget spec generally) were never a
> good
> > fit for the top-level-navigation case. Widgets, as far as I know, were
> > always intended to be single page apps, and the <access> tag wouldn't
> have
> > any affect on that at all.
> >
> > We've used it for nav in the past, though, so the question is whether
> > familiarity with the old syntax trumps the fact that we're changing the
> > behaviour.
> >
> > On Wed Dec 17 2014 at 11:47:02 AM Chuck Lantz <clantz@microsoft.com>
> > wrote:
> >
> > > I suppose that is a good question. I took a look at the Widget Access
> > > Request Policy W3C spec where that element comes from.  It's actually
> > > pretty ambiguous.
> > >
> > > "A user agent enforces an access request policy. ... In the default
> > > policy, a user agent must deny access to network resources external t=
o
> > > the widget by default, whether this access is requested through APIs
> > (e.g.
> > > XMLHttpRequest) or through markup (e.g. iframe, script, img).."
> > >
> > > ... but...
> > >
> > > "A user agent may apply a different default policy if the widget is
> > > being used in a context that defines its own policy, such as for
> > > instance a widget served over HTTP. A more lenient policy can be
> > > defined with the access-request list as defined in the processing
> > > section. ... Furthermore, a user agent may grant access to certain UR=
I
> > > schemes (e.g., mailto:) without the need of an access request if its
> > > security policy considers those schemes benign."
> > >
> > > It strikes me that today we implement the default policy and what
> > > we're proposing here is a more lenient, alternate policy.
> > >
> > > For what it's worth, here's how this is defined in the Windows world:
> > >
> > >       <ApplicationContentUriRules>
> > >           <Rule Match=3D"https://www.google.com" Type=3D"include" />
> > >       </ApplicationContentUriRules>
> > >
> > > -Chuck
> > >
> > > -----Original Message-----
> > > From: Ian Clelland [mailto:iclelland@chromium.org]
> > > Sent: Wednesday, December 17, 2014 8:16 AM
> > > To: dev@cordova.apache.org
> > > Subject: Re: How to handle CSP for XHR in Cordova 4.0
> > >
> > > Definitely want to handle iOS, with the same policy. I've been workin=
g
> > > 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 the <access> elements would map to that in the base platform?
> > > > I'm thinking in 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 fo=
r
> > > > 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 o=
r
> > 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 <acces=
s>
> > > > > > elements in config.xml to the top level nav whitelist for this
> > > > > > reason. CSP isn=E2=80=99t really designed 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 app=
s
> > > > > > 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, ca=
n
> > > > > > > > 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 whol=
e
> > > > > > > > point is
> > > > > > > that
> > > > > > > > they specify in the HTML, not in a config file.) The easies=
t
> > > > > > > > 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, fo=
r
> > > > > > > > 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 i=
t
> > > > > > > > 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 automaticall=
y
> > > > > > > > creates CSP tags *and* updates the XHR whitelist, both from
> > > > > > > > config
> > > > > directives.
> > > > > > > >   * Lots more work
> > > > > > > >   * We probably don't know enough about real requirements t=
o
> > > > > > > > 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
> > > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>

--001a11c2de6462e4a8050a91c223--