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 as a plugin
Date Thu, 09 Oct 2014 14:38:00 GMT
I'm running into more and more problems caused by the whitelist (today,
it's because of the dual use of the internal whitelist for "should be able
to navigate to URL" and "should be able to XHR from URL")

I'm going to start to pull it out, on a topic branch based off of Android
4.0.x right now. I'll create a JIRA issue to track the work.

Is 4.0.x the best place for this to land, or is there any support for
putting it on master as well, for an eventual 3.7 release?


On Wed, Jul 9, 2014 at 1:22 PM, Shazron <shazron@gmail.com> wrote:

> +1 to remove it  for all the above reasons (and WKWebView in iOS 8)
> Those interested in this security blanket for checkmark ✓ purposes can
> install the plugin, and perhaps maintain it as well.
>
> On Wed, Jul 9, 2014 at 10:17 AM, Brian LeRoux <b@brian.io> wrote:
> > Or remove it altogether and let the evolution of that code be maintained
> by
> > those interested in the narrative it provides? :)
> >
> > On Wednesday, July 9, 2014, Andrew Grieve <agrieve@chromium.org> wrote:
> >
> >> Sounds like we both agree that it doesn't work and adds a false sense of
> >> security (to those that do opt into it) :P.
> >>
> >> Maybe what we should do is redesign the whitelist to do something more
> >> useful.
> >>
> >> e.g. A whitelist that says what URLs you can navigate to is useful and
> easy
> >> to implement. Let's just drop the trying to stop network requests
> aspect of
> >> it?
> >>
> >>
> >> On Tue, Jul 8, 2014 at 12:54 PM, Joe Bowser <bowserj@gmail.com
> >> <javascript:;>> wrote:
> >>
> >> > I'm in agreement with Andrew on this one.  If we can get CSP working,
> >> > that's a far better solution than our Whitelist, which was done
> >> > because it was needed at the time for the enterprise use case that IBM
> >> > had.  I don't think we're ever going to stop are users from doing dumb
> >> > things like including thirdpartyadnetworkthatdoesnoteusehttps.js in
> >> > their apps any time soon, but they'll have to jump through more hoops
> >> > to do dumb things, and making dumb things harder is a good thing.
> >> >
> >> > On Tue, Jul 8, 2014 at 9:47 AM, Brian LeRoux <b@brian.io
> <javascript:;>>
> >> wrote:
> >> > > Heh. Why do we always seem to be at the opposite end of
> considerations?
> >> > > (Not a bad thing anyhow. ;)
> >> > >
> >> > > So making whitelist a plugin would most certainly isolate the code
> >> which
> >> > > would help us better understand:
> >> > >
> >> > > 1.) where the surface for bugs are (we seem to miss/find new
> security
> >> > holes
> >> > > each quarter…)
> >> > > 2.) if people actually use it
> >> > >
> >> > > I'm more interested in #2. I suspect the only people whom do use it
> are
> >> > > security researchers disproving the whitelist veracity. I feel this
> API
> >> > was
> >> > > a mistake, is misleading, and ultimately leads to poor web security
> >> > > practices wrt 3rd part scripts. I'd like the evidence to remove it
> >> > > completely and making it a plugin would do that. (And still allow
> for
> >> its
> >> > > existence to those whom want to contribute to a "marketing" based
> api.)
> >> > >
> >> > >
> >> > >
> >> > > On Tue, Jul 8, 2014 at 6:52 AM, Andrew Grieve <agrieve@chromium.org
> >> <javascript:;>>
> >> > wrote:
> >> > >
> >> > >> I don't think moving the whitelist to a plugin would aid in its
> >> > >> understanding. Right now the whitelist is used for two things:
> >> > >>
> >> > >> 1. Whether to allow network requests through (although this is
> broken
> >> > for
> >> > >> <audio>/<video> on iOS, and broken for them + websockets
on Android
> >> > >> 2. Whether to allow top frame navigations (e.g. clicking a link
to
> >> > http://
> >> > >> *
> >> > >> opens in system browser vs. webview)
> >> > >>
> >> > >> #1 doesn't work very well due to technical limitations.
> >> > >> #2 is actually the more import one security-wise I think, and
I
> don't
> >> > think
> >> > >> should be relegated to a plugin.
> >> > >>
> >> > >> I'm hoping medium-term that CSP can replace the use-case of #1.
> >> > >>
> >> > >>
> >> > >> On Mon, Jul 7, 2014 at 10:21 PM, Ian Clelland <
> iclelland@chromium.org
> >> <javascript:;>>
> >> > >> wrote:
> >> > >>
> >> > >> > What would be the security implication of removing it from
core?
> No
> >> > >> access
> >> > >> > at all by default? Or unlimited access by default?
> >> > >> >
> >> > >> > I suspect that if the default policy with no plugin installed
is
> the
> >> > >> > latter, then we will be given the impression that it's not
> important
> >> > at
> >> > >> all
> >> > >> > :)
> >> > >> >
> >> > >> > I had considered just turning the whitelist settings into
a
> plugin
> >> --
> >> > >> > either leaving the default rules as they are, and writing
a
> >> > >> > "cordova-security" plugin that locks it down, or tighten
> everything
> >> by
> >> > >> > default, and tell people to install "cordova-plugin-insecurity"
> if
> >> > they
> >> > >> > want to open it up :)
> >> > >> >
> >> > >> > I like the idea of making the entire whitelist architecture
into
> a
> >> > >> plugin,
> >> > >> > though. If nothing else, it should be easier to reason about
it,
> and
> >> > >> easier
> >> > >> > to fix or replace it in the future if we need to.
> >> > >> >
> >> > >> >
> >> > >> > On Mon, Jul 7, 2014 at 3:55 PM, Shazron <shazron@gmail.com
> >> <javascript:;>> wrote:
> >> > >> >
> >> > >> > > Actually it's already possible in any iOS version, we
just
> have to
> >> > >> > > make sure the plugin loads at startup. This is for UIWebView
> only,
> >> > >> > > WKWebView has this issue:
> >> > >> > > https://issues.apache.org/jira/browse/CB-7049 - you
can't
> >> intercept
> >> > >> > > any requests from it currently (not sure if anything
changed in
> >> iOS
> >> > 8
> >> > >> > > beta 3)
> >> > >> > >
> >> > >> > > On Mon, Jul 7, 2014 at 11:45 AM, Brian LeRoux <b@brian.io
> >> <javascript:;>> wrote:
> >> > >> > > > Was discussing this w/ Shaz and Joe and, in theory,
this is
> >> > possible
> >> > >> > from
> >> > >> > > > iOS8 onward and possibly w/ some refactoring in
the 4.x
> series
> >> of
> >> > >> > > Android.
> >> > >> > > >
> >> > >> > > > Its also probably the single most problematic areas
of
> >> > >> misunderstanding
> >> > >> > > as
> >> > >> > > > it relates to security we have. Isolating it from
core would
> >> give
> >> > us
> >> > >> a
> >> > >> > > > better picture of how important it truly is.
> >> > >> > > >
> >> > >> > > > Thoughts?
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
>

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