Also the whitelist might be important for plugins. Specifically, people that need to install plugins have a promise of what external locations are being accessed.
However, right now all iOS plugins bypass the whitelist because of our User-Agent method, and that needs to be rectified before this "promise" is true. Certain resources bypass the whitelist anyway because we have no way to control them at the moment (audio/video tags): https://issues.apache.org/jira/browse/CB-2451 On Wed, Apr 10, 2013 at 5:22 PM, Shazron <shaz...@gmail.com> wrote: > Ideally we would have a WebPolicyDelegate like OS X > (webView:decidePolicyForMIMEType:): > > https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Protocols/WebPolicyDelegate_Protocol/Reference/Reference.html > > ...where we can have some granularity - I'm not sure we can yet. If so, we > can defer to the app developer whether certain things like images can be > let through - for example in MainViewController, you can set your own > WebPolicyDelegate. We would allow images through by default. > > I'm not sure of "letting the fox in the hen-house" (allow everything) then > trying to guard against attacks (hens with shotguns?), this is JavaScript > after all. I'm interested however in how your gatekeeper concept works to > help with this since allowing an external URL location does not protect > from this attach (think of the situation if the external host was hacked, > and contained JS that attacks/intercepts our bridge). > > With the default wildcard in new projects, like others here have > mentioned, the whitelist is effectively turned off, and 99% of devs won't > care to restrict the whitelist. > > > > On Wed, Apr 10, 2013 at 3:06 PM, Braden Shepherdson > <bra...@chromium.org>wrote: > >> 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 <purplecabb...@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.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 >> > > > >> > > >> > >> > >
