cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@google.com>
Subject Re: How to handle CSP for XHR in Cordova 4.0
Date Fri, 12 Dec 2014 17:34:21 GMT
Default CSP is a good idea. I was worried about leaving new apps vulnerable
by default but that should close that.

Do we know what the CSP story is on all platforms, to know that it won't
break anything else?
On 12 Dec 2014 11:56, "Michal Mocny" <mmocny@chromium.org> wrote:

> I'm fine with 1. coupled with a default CSP in the template application.
>
> For older apps not written from scratch, we can perhaps strongly suggest
> installing the legacy-whitelist, which would change the default-open
> behaviour to default-closed.
>
> Together, that would give sensible defaults that aren't open-to-everything?
>
> -Michal
>
> On Fri, Dec 12, 2014 at 9:13 AM, Ian Clelland <iclelland@chromium.org>
> wrote:
>
> > I'm just building the new optional whitelist plugins for Cordova Android
> > and iOS 4.x, and I'm thinking about how to encourage developers to use
> CSP
> > for network requests, as opposed to a
> > Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve.
> >
> > (Note: This is really just about things like XHR requests, <img> and
> > <script> tags, etc, which are historically the only things that we've
> > reliably been able to filter out. Other classes of network requests just
> > bypass all of our code anyway, which sucks, and frame navigation and
> > external application launches are already well handled by the framework).
> >
> > The policy I've implemented on the unplug-whitelist branches, which at
> > first thought at least *sounds* sane, is that network requests are
> blocked
> > by default. (At least all of the ones that we can intercept). That way, a
> > plugin, such as the legacy-whitelist plugin, can open up access to
> specific
> > resources, and the fallback is safety.
> >
> > To use CSP, though, we have to open up access to the outside, and we
> don't
> > necessarily know what the developer wants to open (the whole point is
> that
> > they specify in the HTML, not in a config file.) The easiest way is to
> open
> > up access to *all* resources to the webview, and then restrict it through
> > the CSP header/meta-tag, which does a better job of blocking those
> requests
> > than we do in any case.
> >
> > I think that we want to encourage developers to use CSP, for a lot of
> > reasons, but I'm going to have to do one of these things, and I'm not
> > entirely sure which is the right one:
> >
> > 1. Open access to all network resources by default in Cordova 4.x.
> >   * This doesn't apply to navigations, or launching other apps. They're
> > still blocked by default.
> >   * Any plugin implementing shouldAllowRequest would still be able to
> turn
> > this into a disallow-by-default whitelist
> >   * We can't block everything anyway (see websockets, audio/video
> streams /
> > probably more), so it removes the illusion that we can.
> >
> > 2. Make another whitelist-y plugin, something like
> "org.apache.cordova.csp"
> > that exists only to open up access to network resources. Direct all users
> > who want to use CSP to install that plugin first
> >   * It's a 4th network plugin (after legacy-whitelist,
> navigation-whitelist
> > and intent-whitelist)
> >   * Adding it doesn't actually add any CSP protection, so it probably
> needs
> > a better name
> >   * It's an extra step that may confuse people and limit adoption
> >
> > 3. Do something crazy. Maybe a CSP plugin that automatically creates CSP
> > tags *and* updates the XHR whitelist, both from config directives.
> >   * Lots more work
> >   * We probably don't know enough about real requirements to get this
> right
> >   * If CSP is doing its job, then the XHR whitelist isn't needed anyway;
> it
> > would just be another layer that isn't doing anything different.
> >
> > I'm leaning towards #1, but its a it's a decision that we really should
> > think about and decide on-list before moving forward.
> >
> > Ian
> >
>

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