cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: How to handle CSP for XHR in Cordova 4.0
Date Tue, 16 Dec 2014 15:20:33 GMT
On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz <clantz@microsoft.com> wrote:
>
> Near term, for Windows 8.0/8.1, a custom security policy is in place at
> the platform level for store apps so CSP doesn't really apply there at the
> moment. (And, to be really specific, CSP support is pretty limited in
> IE10/11 focusing on the sandbox directive. The Windows 10 Tech Preview is
> where you can see the real support in IE right now.) So, it's a more of
> forward-thinking topic in that world.
>
> A related question, however - CSP support only started in the Android
> browser with 4.4 did it not? Obviously Crosswalk would have it but what
> about when using the base browser?  Is the thought devs should use the old
> whitelist model here?
>

I think one of the big issues is that the whitelist never worked for
blocking *all* requests. It didn't work pre-3.0, and it doesn't block
<audio>, <video>, websocket in any version. Supporting the illusion of a
whitelist is probably worse than not supporting it at all.



>
> Safari seems to support it back at least as far as iOS 7 (or 6 with a
> custom header) - the main reason I bring it up is developers could see
> different behaviors between devices and versions if the default CSP policy
> leaves something like inline or eval disabled.
>
> -Chuck
>
> -----Original Message-----
> From: Ian Clelland [mailto:iclelland@chromium.org]
> Sent: Monday, December 15, 2014 11:17 AM
> To: dev@cordova.apache.org
> Subject: Re: How to handle CSP for XHR in Cordova 4.0
>
> On Mon Dec 15 2014 at 11:28:43 AM Chuck Lantz <clantz@microsoft.com>
> wrote:
>
> > For the Windows platform, IE 10 and 11 support CSP 1.0 - there's one
> > subtle difference (X-Content-Security-Policy vs
> > Content-Security-Policy in the HTTP header).  The Win 10 Tech Preview
> already has full CSP support.
> > In general, the conventional wisdom is to push app models towards the
> > CSP and away from custom enforcement policies from our point of view.
> > I love the idea of Cordova heading this same direction.
> >
>
> That's great to hear.
>
> >
> > Windows apps have a URI whitelist focused on top level navigation and
> > JavaScript includes on pages not XHR. The main reason to lock down at
> > this level is to reduce the risk of a malicious user navigating the
> > page to a URI outside of the app author's control and take advantage
> > of sensitive APIs.  So, I think some level of whitelist to help out in
> > this situation is advisable even with CSP being used. We’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" <mmocny@chromium.org> wrote:
> >
> > > I'm fine with 1. coupled with a default CSP in the template
> application.
> > >
> > > For older apps not written from scratch, we can perhaps strongly
> > > suggest installing the legacy-whitelist, which would change the
> > > default-open behaviour to default-closed.
> > >
> > > Together, that would give sensible defaults that aren't
> > open-to-everything?
> > >
> > > -Michal
> > >
> > > On Fri, Dec 12, 2014 at 9:13 AM, Ian Clelland
> > > <iclelland@chromium.org>
> > > wrote:
> > >
> > > > I'm just building the new optional whitelist plugins for Cordova
> > > > Android and iOS 4.x, and I'm thinking about how to encourage
> > > > developers to use
> > > CSP
> > > > for network requests, as opposed to a
> > > > Cordova-implemented-whitelist-which-probably-leaks-like-a-sieve.
> > > >
> > > > (Note: This is really just about things like XHR requests, <img>
> > > > and <script> tags, etc, which are historically the only things
> > > > that we've reliably been able to filter out. Other classes of
> > > > network requests just bypass all of our code anyway, which sucks,
> > > > and frame navigation and external application launches are already
> > > > well handled
> > by the framework).
> > > >
> > > > The policy I've implemented on the unplug-whitelist branches,
> > > > which at first thought at least *sounds* sane, is that network
> > > > requests are
> > > blocked
> > > > by default. (At least all of the ones that we can intercept). That
> > > > way, a plugin, such as the legacy-whitelist plugin, can open up
> > > > access to
> > > specific
> > > > resources, and the fallback is safety.
> > > >
> > > > To use CSP, though, we have to open up access to the outside, and
> > > > we
> > > don't
> > > > necessarily know what the developer wants to open (the whole point
> > > > is
> > > that
> > > > they specify in the HTML, not in a config file.) The easiest way
> > > > is to
> > > open
> > > > up access to *all* resources to the webview, and then restrict it
> > > > through the CSP header/meta-tag, which does a better job of
> > > > blocking those
> > > requests
> > > > than we do in any case.
> > > >
> > > > I think that we want to encourage developers to use CSP, for a lot
> > > > of reasons, but I'm going to have to do one of these things, and
> > > > I'm not entirely sure which is the right one:
> > > >
> > > > 1. Open access to all network resources by default in Cordova 4.x.
> > > >   * This doesn't apply to navigations, or launching other apps.
> > > > They're still blocked by default.
> > > >   * Any plugin implementing shouldAllowRequest would still be able
> > > > to
> > > turn
> > > > this into a disallow-by-default whitelist
> > > >   * We can't block everything anyway (see websockets, audio/video
> > > streams /
> > > > probably more), so it removes the illusion that we can.
> > > >
> > > > 2. Make another whitelist-y plugin, something like
> > > "org.apache.cordova.csp"
> > > > that exists only to open up access to network resources. Direct
> > > > all users who want to use CSP to install that plugin first
> > > >   * It's a 4th network plugin (after legacy-whitelist,
> > > navigation-whitelist
> > > > and intent-whitelist)
> > > >   * Adding it doesn't actually add any CSP protection, so it
> > > > probably
> > > needs
> > > > a better name
> > > >   * It's an extra step that may confuse people and limit adoption
> > > >
> > > > 3. Do something crazy. Maybe a CSP plugin that automatically
> > > > creates CSP tags *and* updates the XHR whitelist, both from config
> directives.
> > > >   * Lots more work
> > > >   * We probably don't know enough about real requirements to get
> > > > this
> > > right
> > > >   * If CSP is doing its job, then the XHR whitelist isn't needed
> > > > anyway;
> > > it
> > > > would just be another layer that isn't doing anything different.
> > > >
> > > > I'm leaning towards #1, but its a it's a decision that we really
> > > > should think about and decide on-list before moving forward.
> > > >
> > > > Ian
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>

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