cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: whitelist as a plugin
Date Tue, 08 Jul 2014 16:47:08 GMT
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> 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>
> 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> 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> 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