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:57:30 GMT
CB-7747, for those following along at home.

On Thu, Oct 9, 2014 at 10:38 AM, Ian Clelland <iclelland@chromium.org>
wrote:

> 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