cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: iOS: The future of whitelisting
Date Wed, 10 Apr 2013 22:06:36 GMT
Especially since permissions, on platforms that have such a notion, will be
(eventually...) controlled by installing those plugins. So you can lean on
the platform to block access to contacts as well. Even on platforms without
such permissions control, if we don't load the contacts-retrieval native
code, then the JS can't get at it.

Braden


On Wed, Apr 10, 2013 at 4:44 PM, Jesse <purplecabbage@gmail.com> wrote:

> I am completely in favor of removing whitelisting as well.  I believe it
> gives developers a false sense of security.
> imho the only sure way to protect access to the bridge is to only ever load
> code that you control. We should be pushing developers towards
> best-practices.
>
> Some of the whitelist stuff should become redundant when we have things
> like the Contact API moved into plugins.  ie. You can be absolutely certain
> that no JS code is accessing the device's contacts if you do not include
> the native pieces of the Contact API.
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Apr 10, 2013 at 1:23 PM, Brian LeRoux <b@brian.io> wrote:
>
> > We recently moved to * by default to ease common userland woe. I'd be in
> > favor of removal of whitelisting but I'm fairly certain that would be
> > a controversial position!
> >
> >
> > On Wed, Apr 10, 2013 at 11:38 AM, Kevin Hawkins <
> > kevin.hawkins.cordova@gmail.com> wrote:
> >
> > > Hey all,
> > >
> > > Those of us who have been on the implementing and/or serious
> consumption
> > > side of whitelisting for iOS—I've been on both at one time or
> > another—know
> > > how much work has gone into trying to make it a full-featured security
> > > subsystem for the iOS version of the framework.  I want to share some
> > > feedback based on my organization's experiences in implementation, and
> > > hopefully spark some discussion about the future of whitelisting on iOS
> > > (and maybe the platform as a whole).
> > >
> > > We're essentially running into insurmountable issues with whitelisting
> > for
> > > the use cases we're attempting, based on the overreach of the
> > NSURLProtocol
> > > approach to whitelist handling.  I say overreach because, in an ideal
> > > world, Cordova should only ever care about safeguarding traffic
> destined
> > to
> > > go through the hybrid/native bridge.  This argument can be made for all
> > > platforms, but the lack of granularity is most onerously overbearing on
> > > iOS, which filters every HTTP(S) packet that goes through the app.
> > >
> > > Our requirements are very strict with regard to what's whitelisted to
> go
> > > through the bridge.  But the bridge is conceptually the only thing we
> > care
> > > about, within that particular sphere of security.  We have a more
> relaxed
> > > sphere of security for, say, <img src="http://maps.google.com" />, as
> > the
> > > threat vectors exposed through image rendering are considerably less
> than
> > > malicious injected bridge code.
> > >
> > > Alas, we don't—and arguably never will—have that kind of granular
> control
> > > in iOS, with the current implementation approach.  NSURLProtocol is
> > simply
> > > too broad-brush to meld into a granular approach for whitelisting.  The
> > end
> > > result is that we lose the ability to deliver a rich content experience
> > > that leverages third party artifacts, because we're forced to go with
> the
> > > sphere of security that gives us the highest scrutiny, across the
> board.
> > >
> > > We've been considering (very early phase) some alternative approaches
> to
> > > managing whitelisting.  Our current thinking has been focusing on a
> > > gatekeeper (on the native side) to the bridge itself.  This would
> enforce
> > > some sort of contract between the hybrid and native side, to make a
> > > determination of which traffic is authorized to specifically go through
> > the
> > > bridge.  I'm not sure what that contract looks like at this point, but
> > > enforcement would be bridge-specific, and all other webview traffic
> would
> > > otherwise behave as it would in a normal web application.
> > >
> > > I know from past discussions that many (most?) Cordova developers don't
> > > generally use the whitelist, since their security concerns may not be
> as
> > > great, and/or they exclusively host their app functionality locally to
> > the
> > > device, which allows them to essentially implement their own controls
> on
> > > attack vectors through selective app content.  In our case, we're
> > building
> > > an enterprise platform where content could come from any number of
> > sources.
> > >  And whitelisting controls are not working for us.
> > >
> > > If there's a future for whitelisting in Cordova 3.0, I personally feel
> > that
> > > it needs to be revisited.  I'd be interested to hear thoughts from
> others
> > > on their usage patterns, and responses to my concerns.
> > >
> > > Cheers,
> > > Kevin
> > >
> >
>

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