A related topic as it pertains to CSP: If we are going down the CSP path, what
are people's thoughts on the security risks associated with inline script
("unsafe-inline") use as a part of the default policy - particularly from
content originating from outside of the Cordova app package? It's obviously a
common practice, but XSS risk inside the app is higher with it enabled.
-Chuck
-----Original Message-----
From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian
Clelland
Sent: Tuesday, August 12, 2014 8:55 AM
To: dev@cordova.apache.org
Subject: Re: [Discuss] 3.6.0 Release
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.
> > >
> >
>
