cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Android's new Whitelist Plugins
Date Wed, 04 Mar 2015 17:06:25 GMT
On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal <nikhilkh@microsoft.com>
wrote:

> Here are my thoughts on the default behavior:
> - navigation should be disabled.
> - XHR & network request should be enabled.
>

And application launch through intent URLs should also be disabled. (IMO)

That's not a bad default -- it enables CSP usage by default, which I think
is good. It also (I think) means we're giving up on suggesting that network
requests can be completely blocked by default, because that's definitely
not the case on Android.

We can implement this within the new framework: there is the idea of a
'default policy' that only comes into effect when no plugins take
responsibility for the whitelist. As soon as any plugin, though, handles
the shouldAllowRequest() call, for instance, the default policy is no
longer in effect, and it is a true whitelist (block-by-default)

My biggest concern with this is that developers are going to blindly update
to Cordova 4.0.0, and when their app *just works*, they are not going to
realize that they are actually less secure than before. (Without a plugin,
we've opened up all network access)

Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on
upgrade -- and if we see any access tag other than <access origin="*"> we
can display a loud message, suggesting strongly that they install an
appropriate plugin.

Ian


>
> The plugin name is fine.
>
> I'm not convinced about a user having to add this plugin to enable network
> requests for Android/iOS. This default behavior should work with the
> platform and should not require a plugin. This inhibits users from getting
> the ground running on a Cordova app. It breaks existing templates in IDEs
> and other downstream CLIs as well - as all of them need to include this
> plugin to have any network access work.
>
> Thanks,
> Nikhil
>
>
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> Mocny
> Sent: Tuesday, March 3, 2015 11:22 AM
> To: dev
> Subject: Re: Android's new Whitelist Plugins
>
> I've filed a JIRA issue with my thoughts on how to approach this:
> https://issues.apache.org/jira/browse/CB-8597
>
> On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
> > Like your ideas a lot. Updating the project template makes a lot of
> sense.
> >
> > Tried to make it clear in the README, so if any part was not clear
> > please fix it. But, the CSP tag is the more important bit, since
> > <access> can't actually block all requests. The only reason to even
> > leave <access> in there is to support pre-kitkat webviews, where no
> > CSP support exists. CSP is also used to set a navigation whitelist for
> > subframes, which the native side is not able to do.
> >
> > On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> >
> > > My thoughts:
> > >
> > > - The split between <allow-navigation>, <allow-intent>, and <access>:
> > Like
> > > it a lot.
> > > - I think the defaults *for the plugin* are very reasonable.
> > > However, we may want to provide a default set of tags for the hello
> > > world app.  A
> > year
> > > or so ago we added a default access * whitelist and I think maybe we
> > should
> > > continue that.  (on the other hand, I've gotten used to explicitly
> > > whitelisting every url as part of chrome packaged app development
> > > and its not so bad).
> > >   - Additionally, that means this plugin should be installed by
> default.
> > > As we discussed this morning, with the new plugin --save
> > > functionality we could just add this to the helloworld config.xml, I
> think!
> > > - Do you really need a CSP meta tag *and* <access> declarations?
>  Thats
> > > what the README.md implies, but I would assume CSP trumps?
> > >
> > > -Michal
> > >
> > > On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve <agrieve@chromium.org>
> > > wrote:
> > >
> > > > I've tried to explain it in the plugin's readme:
> > > >
> > > > https://github.com/apache/cordova-plugins/tree/master/url-policy
> > > >
> > > > Some points for discussion:
> > > > - What should the default behaviour be for the three whitelists
> > > > (what should happen if not whitelist plugin is installed).
> > > >   - right now it can't open external URLs
> > > >   - and can't do XHRs to http(s)
> > > > - Is the plugin name decent ("url-policy"). We should make a
> > > > dedicated
> > > git
> > > > repo for it (as well as for legacy-whitelist plugin)
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message