cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: iOS: The future of whitelisting
Date Wed, 10 Apr 2013 20:23:09 GMT
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 <> 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="" />, 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

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