cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Whitelist breakout update
Date Wed, 12 Nov 2014 13:58:07 GMT
Sorry for dropping this thread for a week; let me see if I can address that
--

By default, for brand new apps created with Cordova 4.x with no plugins,
those will be blocked (this includes protocols like tel: and mailto:) .
This was considered to be a security issue earlier this year, and we put
measures unto Cordova 3.5.1 to ensure that Cordova apps couldn't launch
other intents without the app author's cooperation. (This makes Cordova
apps a bit more like native apps, and a bit less like websites, when
displaying external content, which is probably a good thing re: security)

If you add the cordova-legacy-whitelist plugin, then you get back exactly
the same level of control that you had with Cordova, say, 3.7.0, and the
goal is that you don't have to do anything else to get backwards
compatibility. If you find any regressions, bring them up on the list or in
JIRA, and we should be able to resolve them. (Hopefully before 4.0.0 is
released).

Any other behaviour that you need should be possible through a plugin;
whether that means a custom one for your app, or something from the
community that hundreds of other devs use, I don't know :)

On Tue Nov 04 2014 at 11:11:57 AM Frederico Galvão <
frederico.galvao@pontoget.com.br> wrote:

> I understand and am already familiar with the configuration for external
> URLs that do not interfere/launch third party apps or intents.
> I just want to understand better what's gonna happen with the custom
> protocols I call, like tel: or mailto:, or even URLs that have custom
> handlers on each platform.
>
> 2014-11-04 14:03 GMT-02:00 Ian Clelland <iclelland@chromium.org>:
>
> > On Tue Nov 04 2014 at 10:46:52 AM Frederico Galvão <
> > frederico.galvao@pontoget.com.br> wrote:
> >
> > > So we actually have 4 new plugins:
> > > org.apache.cordova.whitelist
> > > org.apache.cordova.legacy-whitelist
> > > org.apache.cordova.navigation-whitelist
> > > org.apache.cordova.intent-whitelist
> > >
> >
> > I think that org.apache.cordova.legacy-whitelist is a better name for
> what
> > I have published at https://github.com/clelland/cordova-plugin-whitelist
> > as
> > org.apache.cordova.whitelist.
> >
> > So where I had a single plugin implementing the old behaviour, Andrew has
> > suggested releasing three plugins: legacy-whitelist, which is what I
> > implemented; and two new ones: navigation-whitelist, which implements
> > navigation control, and intent-whitelist, which would control launching
> > external apps.
> >
> > (And there's also the very sound advice of "just skip the whitelist
> plugins
> > and use CORS if you can get away with it")
> >
> > >
> > > Right?
> > >
> > > If that's the case, then this is not entirely true:
> > >
> > > If what
> > > > you want is no change at all in behaviour, then your upgrade should
> be
> > > > just:
> > > >
> > > > cordova plugin add org.apache.cordova.whitelist
> > > >
> > > > There would be no configuration changes to make: the plugin reads the
> > old
> > > > access tags, just as before, and applies the same policies based on
> > them
> > > > that it did in 3.6.
> > > >
> > >
> >
> >
> > The messaging is still simple, if all you want is backwards
> compatibility,
> > but if you want something better, then the instructions are more
> > complicated, and depend on your actual needs.
> >
> >
> > >
> > > 2014-11-04 2:13 GMT-02:00 Andrew Grieve <agrieve@chromium.org>:
> > >
> > > > Since the whitelist plugin blocks only a subset of sub-resource loads
> > > (just
> > > > like the existing whitelists), I think we really want to call out
> that
> > > > people should not just include the backwards-compatible plugin.
> Here's
> > a
> > > > stab at messaging:
> > > >
> > > >
> > > > If you want nothing to change, use org.apache.cordova.legacy-
> whitelist.
> > > If
> > > > you care about security, then please understand that there are three
> > > types
> > > > of whitelists to consider:
> > > >
> > > > 1. Network traffic - The whitelist has never been able to fully block
> > all
> > > > network requests in this manner (on iOS and Android). Instead, we
> > > recommend
> > > > using <meta http-equiv="Content-Security-Policy" content="[POLICY
> GOES
> > > > HERE]"> in your <head>, which is supported on Android 4.4 and
iOS 7.
> > > >
> > > > 2. Navigation - By default the webview is allowed to navigate to any
> > page
> > > > within the same directory tree as the start page. If you'd like to
> > > navigate
> > > > to a different directory, or to a http(s) address, then you should
> use
> > > > org.apache.cordova.navigation-whitelist.
> > > >
> > > > 3. Intents - By default all URLs that cause an external action (e.g.
> > > tel:,
> > > > sms:, etc) are disabled. If you need to use any of these, then you
> > should
> > > > use org.apache.cordova.intent-whitelist.
> > > >
> > > >
> > > > On Mon, Nov 3, 2014 at 10:08 PM, Ian Clelland <
> iclelland@chromium.org>
> > > > wrote:
> > > >
> > > > > On Mon Nov 03 2014 at 4:05:51 PM Marcel Kinard <cmarcelk@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > > This sounds very interesting and relatively graceful.
> > > > > >
> > > > > > For a user upgrading to this new world, what would the migration
> > > steps
> > > > > > look like? Or in other words, what would a rough sketch of the
> > > upgrade
> > > > > > guide for this look like? The reason I ask is to see how much
> pain
> > > > we'll
> > > > > > ask our users to go through.
> > > > > >
> > > > >
> > > > > That's certainly a concern -- so for one thing, this would have to
> be
> > > on
> > > > a
> > > > > 4.x version of any platforms that it applies to. It is a break in
> > > > backwards
> > > > > compatibility, so users should at least be prepared for it.
> > > > >
> > > > > That said, I've tried to make it as simple as possible for them:
If
> > > what
> > > > > you want is no change at all in behaviour, then your upgrade should
> > be
> > > > > just:
> > > > >
> > > > > cordova plugin add org.apache.cordova.whitelist
> > > > >
> > > > > There would be no configuration changes to make: the plugin reads
> the
> > > old
> > > > > access tags, just as before, and applies the same policies based
on
> > > them
> > > > > that it did in 3.6.
> > > > >
> > > > > And if your application doesn't rely on access to external sites,
> > then
> > > > it's
> > > > > even simpler -- don't install the plugin, and you're likely more
> > secure
> > > > > than you were before.
> > > > >
> > > > >
> > > > > > On Oct 30, 2014, at 4:04 PM, Ian Clelland <
> iclelland@chromium.org>
> > > > > wrote:
> > > > > >
> > > > > > > I've spent the majority of the week finishing up the
> > > > whitelist-breakout
> > > > > > > code, and I'd invite the rest of the community to take
a look,
> > > before
> > > > > we
> > > > > > > make anything official.
> > > > > >
> > > > > > ------------------------------------------------------------
> > > ---------
> > > > > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > *Frederico Galvão*
> > >
> > > Diretor de Tecnologia
> > >
> > > PontoGet Inovação Web
> > >
> > >
> > > ( +55(62) 8131-5720
> > >
> > > * www.pontoget.com.br <http://www.pontoget.com/>
> > >
> >
>
>
>
> --
>
> *Frederico Galvão*
>
> Diretor de Tecnologia
>
> PontoGet Inovação Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>

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