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.cord...@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 >
