cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Hawkins <>
Subject iOS: The future of whitelisting
Date Wed, 10 Apr 2013 18:38:57 GMT
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.


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