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 >
