A malicious XSS that navigates the page would probably opt to not include cordova.js :P.
So - I see there being three kinds of things to have whitelists for: 1) Top-level navigations, 2) intents (on supported platforms) 3) resources / CSP-related requests. According to CSP docs here: https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives You cannot use CSP to control 1). Right now the whitelist tries to cover 1) and 3), but I think from this thread: http://markmail.org/thread/hbr5tlopbbl4pnl3 That we agreed to change it to cover only 1), Although this conversation will likely be more all-encompassing. Options for specifying 1), 2), 3): A) Keep all three separate, with 1) and 2) in config.xml, and 3) in a <meta> added by the user B) Augment the CSP syntax with support for 1) and 2) (as Parashuram suggested), and have cordova.js extract 1) and 2) out of the <meta>, which is added by the user. Make the whitelists empty until cordova.js does the extraction. C) Have them all specified in config.xml, and have Cordova somehow enforce 3) on page load. Another factor: What is put in config.xml is open to be modified by plugins (for better or for worse). Might be useful, but I'm not sure of a concrete use-case (maybe Camera plugin would need this?) As Ian pointed out, C) isn't really feasible on Android in all cases, but I'm torn between A) and B). On Tue, Aug 12, 2014 at 11:59 AM, Michal Mocny <mmo...@chromium.org> wrote: > Any page navigations have to include cordova.js, right? What about > injecting the meta tag before deviceready? > > > On Tue, Aug 12, 2014 at 11:54 AM, Ian Clelland <iclell...@chromium.org> > wrote: > > > I love the idea of using CSP for this, especially because it handles > things > > that our whitelist intercept code can't, like <video> tags and > WebSockets. > > > > The problem that I've found with it is that we can only enforce it for > > single-page apps. We can inject our own CSP headers into the > application's > > start page very easily, but if the user can leave that page and load > > another, then the headers will no longer apply. The WebView interface > won't > > let use add headers to subsequent pages, so it's up to the developer to > > include them in a <meta> tag instead. (and malicious attackers, of > course, > > won't) > > > > For now, I would encourage devs to include that <meta> tag on *all* of > the > > pages in their apps, but we can't do it automatically. > > > > If it turns out that we can, then I'd be on board with including that in > > the 4.0 branch. It's a much better way to do it. Then we'd only need the > > second whitelist for launching intents, I think. > > > > Ian > > > > > > On Tue, Aug 12, 2014 at 11:48 AM, Parashuram Narasimhan (MS OPEN TECH) < > > panar...@microsoft.com> wrote: > > > > > Had a quick question on the whitelists. I remember that there was talk > of > > > using CSP to fix this issue. A CSP file may not be backward compatible, > > but > > > could potentially just give us one list instead of 2 whitelists. The > CSP > > > file may be like the following > > > > > > Content-Security-Policy: > > > script-src 'self', foo.com, bar.com > > > img-src cdn.com > > > intent-src mail, sms > > > > > > Note the new intent-src directive, that is basically used to launch > > > external programs. Do you think this could be something we can look at, > > for > > > 4.0 ? I am not sure if our whitelist xml file maps to a W3C spec, but > CSP > > > seems more like a standard. This is breaking, and 4.0 may be the right > > time > > > to do it ? > > > > > > -----Original Message----- > > > From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of > > Ian > > > Clelland > > > Sent: Tuesday, August 12, 2014 8:30 AM > > > To: dev@cordova.apache.org > > > Subject: Re: [Discuss] 3.6.0 Release > > > > > > I've created CB-7291 for the whitelist issue, and I've ported the code > > > from June to the new-style configuration architecture and committed it > > to a > > > named CB-7291 branch on cordova-android. > > > > > > If anyone has any thoughts/opinions on the syntax or the proposal > itself, > > > or on what the defaults should be for new and upgrading applications, > > > please chime in on the issue. > > > > > > > > > > > > On Mon, Aug 11, 2014 at 11:26 AM, Parashuram Narasimhan (MS OPEN TECH) > < > > > panar...@microsoft.com> wrote: > > > > > > > I think we should also finalize on the platform switches so that we > > > > all agree on a pattern (even if it is different across platforms). > > > > This way, we can release 3.6.0 with a set of switches, and ensure > that > > > > it is backward compatible. > > > > > > > > > > > > -----Original Message----- > > > > From: iclell...@google.com [mailto:iclell...@google.com] On Behalf > Of > > > > Ian Clelland > > > > Sent: Monday, August 11, 2014 8:00 AM > > > > To: dev@cordova.apache.org > > > > Subject: Re: [Discuss] 3.6.0 Release > > > > > > > > I'll see about committing that today; I've had to reorganize it quite > > > > a bit after the Big Config Refactor. > > > > > > > > Joe, I'm pretty certain that your code is still in master, but > > > > definitely add those tests to make sure, and to make sure we don't > > > regress. > > > > > > > > Ian > > > > > > > > > > > > On Mon, Aug 11, 2014 at 10:52 AM, Marcel Kinard <cmarc...@gmail.com> > > > > wrote: > > > > > > > > > I agree with Joe. > > > > > > > > > > On Aug 11, 2014, at 10:02 AM, Joe Bowser <bows...@gmail.com> > wrote: > > > > > > > > > > > Let's not release until the new whitelist is figured out. That > > > > > > feature > > > > > is > > > > > > too important. > > > > > > > > > > > > > > >
