On Mon, Dec 15, 2014 at 8:19 PM, Chuck Lantz <cla...@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:iclell...@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 <cla...@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:iclell...@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" <mmo...@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 > > > <iclell...@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-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > >
