cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: whitelist as a plugin
Date Wed, 09 Jul 2014 17:22:53 GMT
+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
View raw message