You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Ian Clelland <ic...@chromium.org> on 2014/12/12 15:13:48 UTC
How to handle CSP for XHR in Cordova 4.0
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
RE: How to handle CSP for XHR in Cordova 4.0
Posted by Chuck Lantz <cl...@microsoft.com>.
With that in mind, perhaps the thing to do here is to reuse access. Will the nav whitelist be in the base? That would indicate to me it should reuse access for upgrade situations. There's already the "launch-external" attribute that's non-standard so if we have to we could add another attribute.
If we essentially say that CSP + nav whitelist is the recommended pattern, then the xhr whitelist becomes the exception. Do we expect that people will want to use both nav and XHR? I kind of think you'd use one or the other since XHR also blocks nav. That would mean that the <access> element could be used in either situation and you simply see a different behavior with the XHR plugin installed.
-Chuck
-----Original Message-----
From: Ian Clelland [mailto:iclelland@chromium.org]
Sent: Friday, December 19, 2014 5:34 AM
To: dev@cordova.apache.org
Subject: Re: How to handle CSP for XHR in Cordova 4.0
On Thu Dec 18 2014 at 9:42:18 AM Andrew Grieve <ag...@chromium.org> wrote:
> That's a good point Chuck. Since the meaning of <access> would be
> changing 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 <cl...@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 <cl...@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 to 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 URI 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="https://www.google.com" Type="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
> > > 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
> > > <cl...@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
> > > > <cl...@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
> > > > > <cl...@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’ve
> > > > > > mapped <access> elements in config.xml to the top level nav
> > > > > > whitelist for this reason. CSP isn’t 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 – 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" <mm...@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
> > > > > > > <ic...@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
> > > > > >
> > > > >
> > > >
> > >
> > > ------------------------------------------------------------------
> > > --- 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
> >
>
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Ian Clelland <ic...@chromium.org>.
On Thu Dec 18 2014 at 9:42:18 AM Andrew Grieve <ag...@chromium.org> wrote:
> That's a good point Chuck. Since the meaning of <access> would be changing
> 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 <cl...@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 <cl...@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 to
> > > 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 URI
> > > 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="https://www.google.com" Type="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 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 <cl...@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 <cl...@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
> > > > > <cl...@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’ve mapped <access>
> > > > > > elements in config.xml to the top level nav whitelist for this
> > > > > > reason. CSP isn’t 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 – 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" <mm...@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
> > > > > > > <ic...@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
> > > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Andrew Grieve <ag...@chromium.org>.
That's a good point Chuck. Since the meaning of <access> would be changing
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 <cl...@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?
>
> -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 <cl...@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 to
> > 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 URI
> > 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="https://www.google.com" Type="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 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 <cl...@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 <cl...@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
> > > > <cl...@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’ve mapped <access>
> > > > > elements in config.xml to the top level nav whitelist for this
> > > > > reason. CSP isn’t 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 – 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" <mm...@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
> > > > > > <ic...@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
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
RE: How to handle CSP for XHR in Cordova 4.0
Posted by Chuck Lantz <cl...@microsoft.com>.
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?
-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 <cl...@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 to
> 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 URI
> 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="https://www.google.com" Type="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 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 <cl...@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 <cl...@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
> > > <cl...@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’ve mapped <access>
> > > > elements in config.xml to the top level nav whitelist for this
> > > > reason. CSP isn’t 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 – 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" <mm...@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
> > > > > <ic...@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
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> 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
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Ian Clelland <ic...@chromium.org>.
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 <cl...@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 to 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 URI 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="https://www.google.com" Type="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 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 <cl...@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 <cl...@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 <cl...@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’ve mapped <access> elements in config.xml to the
> > > > top level nav whitelist for this reason. CSP isn’t 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 – 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" <mm...@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
> > > > > <ic...@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
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: How to handle CSP for XHR in Cordova 4.0
Posted by Chuck Lantz <cl...@microsoft.com>.
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 to 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 URI 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="https://www.google.com" Type="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 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 <cl...@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 <cl...@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 <cl...@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’ve mapped <access> elements in config.xml to the
> > > top level nav whitelist for this reason. CSP isn’t 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 – 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" <mm...@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
> > > > <ic...@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
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Ian Clelland <ic...@chromium.org>.
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 <cl...@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 <cl...@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 <cl...@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’ve mapped <access> elements in config.xml to the top
> > > level nav whitelist for this reason. CSP isn’t 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
> > > – 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" <mm...@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
> > > > <ic...@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
> > >
> >
>
RE: How to handle CSP for XHR in Cordova 4.0
Posted by Chuck Lantz <cl...@microsoft.com>.
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 <cl...@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 <cl...@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’ve mapped <access> elements in config.xml to the top
> > level nav whitelist for this reason. CSP isn’t 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
> > – 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" <mm...@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
> > > <ic...@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
> >
>
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Andrew Grieve <ag...@chromium.org>.
On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz <cl...@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 <cl...@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’ve mapped
> > <access> elements in config.xml to the top level nav whitelist for
> > this reason. CSP isn’t 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 –
> > 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" <mm...@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
> > > <ic...@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
> >
>
RE: How to handle CSP for XHR in Cordova 4.0
Posted by Chuck Lantz <cl...@microsoft.com>.
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?
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 <cl...@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’ve mapped
> <access> elements in config.xml to the top level nav whitelist for
> this reason. CSP isn’t 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 –
> 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" <mm...@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
> > <ic...@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
>
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Ian Clelland <ic...@chromium.org>.
On Mon Dec 15 2014 at 11:28:43 AM Chuck Lantz <cl...@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’ve mapped <access> elements in
> config.xml to the top level nav whitelist for this reason. CSP isn’t 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 – 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" <mm...@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 <ic...@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
>
RE: How to handle CSP for XHR in Cordova 4.0
Posted by Chuck Lantz <cl...@microsoft.com>.
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.
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’ve mapped <access> elements in config.xml to the top level nav whitelist for this reason. CSP isn’t really designed to help with this kind of problem.
Perhaps a default CSP policy in the template coupled with a top level nav whitelist is the right starting point. Determining what the CSP policy looks like will be really important – by default CSP blocks both inline and eval use. Of the two, inline use tends to be the bigger risk factor.
-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" <mm...@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 <ic...@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
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Ian Clelland <ic...@google.com>.
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" <mm...@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 <ic...@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
> >
>
Re: How to handle CSP for XHR in Cordova 4.0
Posted by Michal Mocny <mm...@chromium.org>.
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 <ic...@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
>