cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Lantz <cla...@microsoft.com>
Subject RE: How to handle CSP for XHR in Cordova 4.0
Date Tue, 16 Dec 2014 01:19:16 GMT
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 <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
View raw message