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 <cla...@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: agri...@google.com [mailto:agri...@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 <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 > > > > > >
