cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: [iOS 8] WKWebView moving forward
Date Thu, 06 Nov 2014 19:15:28 GMT
Thanks Tony - I'll look at that PR when I have some time.

Yesterday I did some major work to isolate the webviews into plugins
(CDVWKWebViewEngine, CDVUIWebViewEngine). This way we can reduce the risk
by extracting the WKWebView items into a plugin, and the core has no
dependency on WebKit.framework anymore, plus speedy (well, speedier)
updates if it needs updating. The CDVUIWebViewEngine will remain in the
core as the default engine. I'm still working on this, but it already works
currently. I'm abstracting things out more, and removing code from the
CDVViewController which has become unwieldy.

Swapping out engines would use the preference:
    <preference name="CordovaWebViewEngine" value="CDVWKWebViewEngine" />

Any new web engine needs to implement the new CDVWebViewEngineProtocol
protocol, and installed as a plugin.

On Mon, Nov 3, 2014 at 6:55 PM, Homer, Tony <tony.homer@intel.com> wrote:

> I have already forked it and made the changes in a topic branch.
> I was originally thinking that I would make 2 topic branches: 1 for
> localhost-only and 1 for auth tokens.
> However, after I finished the first set of changes I realized that the
> second set would be dependent on the first.
> I’ll submit a pull request tomorrow for you to look at - I’ll be happy to
> redo it as multiple branches if that makes sense.
>
> I got a little sidetracked with local web server plugin, but I’ve also
> forked cordova-ios and made a topic branch from wkwebview.
> I'll start working on some of the changes I proposed earlier in this
> thread tomorrow (for plugins like camera that return file:// urls, etc.).
>
> Tony
>
> On 11/3/14, 7:23 PM, "Shazron" <shazron@gmail.com> wrote:
>
> >Thanks Tony for all the investigation. Please do fork the local web server
> >plugin and put all your work in topic branches for eventual pull requests
> >to the main repo.
> >
> >This is precisely why the local web server is a plugin, and not in the
> >core. I don't profess to be a security expert, and we can update this
> >plugin to cover most of the security cases or someone else can provide
> >their better plugin. I don't think this needs to be bulletproof, not that
> >we can entirely be (has there ever been a Security Update by Apple that
> >*didn't* include a WebKit vulnerability?)
> >
> >I'd like to get the cordova-ios/wkwebview branch back into the mainline as
> >soon as possible, but under an experimental flag (--experimental ?)  for
> >bin/create. This will choose a new template that has WebKit.framework in
> >it, which will also define a macro to conditionally compile the new bits
> >in
> >(I haven't added the macros yet in the topic branch).
> >
> >
> >
> >
> >On Mon, Nov 3, 2014 at 7:27 AM, Homer, Tony <tony.homer@intel.com> wrote:
> >
> >> I spent a lot of time thinking about ways to avoid replay attacks for
> >>the
> >> local web server plugin this weekend.
> >>
> >> Specifically, I felt like there should be a way to take advantage of the
> >> fact that the client and the server are running in the same process.
> >> I thought this might enable some kind of sideband (non-http)
> >> authentication possibility.
> >> The 2 possibilities I was most interested in, but eventually concluded
> >>are
> >> not practical were:
> >> 1. unique token per http request - not practical because there is no per
> >> http request event available
> >> 2. a whitelist of “remote” ports - not practical because there is no
> >> simple way to get a list of ports in use by WKWebView
> >>
> >> After going down this rathole and coming up empty, I reconsidered the
> >> original problem and came to the following conclusions.
> >> 1. restricting requests to localhost-only limits “attacks” to
> >>backgrounded
> >> apps
> >> 2. including a token in the requests will prevent backgrounded apps from
> >> being able to successfully make unwanted requests
> >> 3. the token is vulnerable to network analysis, but that cannot be done
> >>on
> >> device
> >>
> >> Therefore, vulnerability is limited to the case where the there is
> >> (1) a “hostile" app installed on device and running in the background
> >>and
> >> (2) the user’s device is connected to a wi-fi network where an attacker
> >>is
> >> able to perform network analysis to capture the token.
> >> In this case, the attacker could just inspect the HTTP traffic instead
> >>of
> >> capturing the token and sending it to their backgrounded app.
> >> In other words, it seems that replay attacks are possible but not
> >>useful.
> >> If we care about the “hostile wifi network” case, we need something like
> >> SSL.
> >>
> >> On 11/1/14, 4:28 PM, "Homer, Tony" <tony.homer@intel.com> wrote:
> >>
> >> >I started looking at how to make the camera plugin be able to work in
> >> >WKWebView.
> >> >Before, I had mentioned intercepting resource requests as a way to fix
> >>the
> >> >file:// requests.
> >> >However, WKWebView does not offer a way to intercept resource requests
> >>so
> >> >that won’t work.
> >> >:/
> >> >
> >> >Andrew had suggested introducing some proxy paths as a way to deal with
> >> >the path problems, which seems fine.
> >> >On the other hand, the request handlers could just inspect the path in
> >>the
> >> >request and do the right thing - are the proxy paths needed?
> >> >I think implicit in those comments was a suggestion that the affected
> >> >plugins such as camera could return URLs using those paths.
> >> >The thing about changing camera and file plugins to support localhost
> >>that
> >> >bothers me, is that now those core plugins effectively support a
> >>non-core
> >> >plugin.
> >> >Also, other (on-cordova) plugins that depend on file protocol will be
> >> >incompatible with the local web server wkwebview solution (unless they
> >> >make changes to support it).
> >> >
> >> >I wonder if it would be better to handle this in CDVPluginResult?
> >> >A hook could be added to initWithStatus and exposed to plugins.
> >> >Then the SALocalWebServer plugin can use the hook to inspect the
> >>message
> >> >and fix it, if it is a file:// URL.
> >> >So, for example, when camera calls CDVPluginResult
> >> >resultWithStatus:messageAsString and passes in a file URL,
> >>SALocalServer
> >> >can get a chance to inspect and modify the result – changing it to an
> >> >http:localhost URL.  It could simply replace the file protocol with
> >> >http://localhost:port, then the handler could decode the path before
> >> >building the response.
> >> >This is ugly, but it would prevent the need to change the camera and
> >>file
> >> >and should allow other non-cordova plugins that depend on file:// URLs
> >>to
> >> >work.
> >> >
> >> >
> >> >Tony
> >> >
> >> >On 10/31/14, 2:03 PM, "Homer, Tony" <tony.homer@intel.com> wrote:
> >> >
> >> >>I started with cookies in my POC, but I was concerned about replay
> >> >>attacks.
> >> >>I couldn’t think of a way to avoid replay vulnerability with cookies
> >> >>(without SSL), so I was going to switch to the side channel approach
I
> >> >>tried to describe.  Do you think replay vulnerability is irrelevant?
> >>I’m
> >> >>not a security guy, so I wasn’t sure if it mattered or not. That’s
> >> >>actually one of the things I was hoping to get feedback about.
> >> >>
> >> >>I guess I don’t follow how CORS relates to the camera plugin, does
it
> >>use
> >> >>XHR? Maybe you can elaborate?
> >> >>I expect I’ll see it when I try the camera plugin from WKWebView,
just
> >> >>didn’t get around to it yet.
> >> >>The only thing that jumps out at me is that you get a file:// url
> >>back -
> >> >>we could change that.
> >> >>Or maybe intercept file:// requests in the plugin?  If it’s just a
> >>path
> >> >>problem, maybe we could intercept the request, fix the path, then
> >>respond
> >> >>with the right thing...
> >> >>
> >> >>Tony
> >> >>
> >> >>On 10/31/14, 1:19 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >> >>
> >> >>>Unless you're having the server proxy requests to remote sites,
I
> >>don't
> >> >>>think CORS headers are necessary.
> >> >>>
> >> >>>Tony - awesome stuff! absolutely doing it right. More
> >>technical-focused
> >> >>>discussion the better :). Using cookies seems the best way to me
> >>since
> >> >>>that
> >> >>>covers all requests. Adding headers works only for XHRs.
> >> >>>
> >> >>>On Fri, Oct 31, 2014 at 12:12 PM, Kirk Shoop (MS OPEN TECH) <
> >> >>>Kirk.Shoop@microsoft.com> wrote:
> >> >>>
> >> >>>> Yes, the handler should be able to add CORS headers to its
> >>responses
> >> >>>>that
> >> >>>> will enable requests from any origin.
> >> >>>>
> >> >>>> For instance adding 'Access-Control-Allow-Origin: *' would
allow
> >>any
> >> >>>> origin to make a request from the local server.
> >> >>>>
> >> http://www.w3.org/TR/cors/#access-control-allow-origin-response-header
> >> >>>>
> >> >>>> Similarly Access-Control-Allow-Methods and
> >> >>>>Access-Control-Allow-Headers
> >> >>>> could be used to define valid requests.
> >> >>>>
> >> >>>> Kirk
> >> >>>>
> >> >>>> Developer
> >> >>>> Microsoft Open Technologies, Inc.
> >> >>>>
> >> >>>> -----Original Message-----
> >> >>>> From: Homer, Tony [mailto:tony.homer@intel.com]
> >> >>>> Sent: Friday, October 31, 2014 8:40 AM
> >> >>>> To: dev@cordova.apache.org
> >> >>>> Subject: Re: [iOS 8] WKWebView moving forward
> >> >>>>
> >> >>>> Last night I added a handler to the Local Web Server plugin
that
> >> >>>>returns
> >> >>>> 403 for non-localhost requests.
> >> >>>> The handler also has a prototype token system to restrict requests
> >>to
> >> >>>>the
> >> >>>> app, but I need to change the approach a bit.
> >> >>>> Currently I set a cookie and the handler just checks for the
cookie
> >> >>>>and
> >> >>>> returns 403 if it is missing.
> >> >>>> This is susceptible to replay attacks from backgrounded apps
- not
> >> >>>>sure
> >> >>>>if
> >> >>>> that is important or not.
> >> >>>>
> >> >>>> I¹m going to investigate adding a map to the plugin, then
add an
> >>entry
> >> >>>>for
> >> >>>> every request.
> >> >>>> The entry will be a hash of the request and a random number.
> >> >>>>
> >> >>>> I¹ll have to wire up support for overriding url loads so that
I can
> >> >>>>add
> >> >>>> the header with the random number to the request.
> >> >>>> Then the request handler will look the entry up in the map
and
> >>remove
> >> >>>>it -
> >> >>>> this should eliminate re-playability.
> >> >>>>
> >> >>>> I¹m not sure about the CORS issue with camera pluginŠ I¹ll
be
> >>curious
> >> >>>>to
> >> >>>> test it - maybe it could be addressed by modifying the response
in
> >>the
> >> >>>> GCDWebServer handler?
> >> >>>>
> >> >>>> Tony
> >> >>>>
> >> >>>> P.S. This is my first attempt participating in discussion on
the
> >>list
> >> >>>>-
> >> >>>> let me know if I¹m doing it wrong!
> >> >>>> Am I wasting my time investigating this?  Should I just leave
it
> >> >>>>Shazron?
> >> >>>>
> >> >>>> On 10/30/14, 9:52 PM, "Andrew Grieve" <agrieve@chromium.org>
> wrote:
> >> >>>>
> >> >>>> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <shazron@gmail.com>
> >>wrote:
> >> >>>> >
> >> >>>> >> The port conflict situation has been solved with the
latest
> >>version
> >> >>>> >>of the  plugin. Passing in a port of "0" will choose
a random
> >>port.
> >> >>>> >>More details in  the plugin's README.md
> >> >>>> >>
> >> >>>> >Awesome! Why even allow a non-random port?
> >> >>>> >Also learned today that in chrome, webcrypto API is disabled
for
> >>http
> >> >>>> >origins, but enabled for https. Not sure if this is true
for
> >>Safari
> >> >>>>as
> >> >>>> >well, but certainly this change will be a can of worms!
> >> >>>> >
> >> >>>> >
> >> >>>> >>
> >> >>>> >> Ouch - didn't think about Camera plugin and File plugin
impact.
> >> >>>>That
> >> >>>> >>proxy  thing might work, as long as there are no folder
name
> >> >>>> >>collisions.
> >> >>>> >>
> >> >>>> >Prefixing all resources into a fake top-level directory
will
> >> >>>>eliminate
> >> >>>> >the folder name collision problem I think.
> >> >>>> >
> >> >>>> >
> >> >>>> >>
> >> >>>> >> My point regarding mixing WKWebView and UIWebView
on iOS 8 is,
> >>if
> >> >>>>you
> >> >>>> >>have  a user on iOS 8.x, you want all users on that
iOS version
> >>to
> >> >>>> >>have the same  experience, and for bug reporting purposes.
> >> >>>> >
> >> >>>> >
> >> >>>> >> On Wed, Oct 29, 2014 at 5:11 PM, Andrew Grieve
> >> >>>><agrieve@chromium.org>
> >> >>>> >> wrote:
> >> >>>> >>
> >> >>>> >> > We could restrict access to the webserver by
stuffing a cookie
> >> >>>>into
> >> >>>> >>the
> >> >>>> >> > webview with an access token, then have the server
just 500 on
> >> >>>>any
> >> >>>> >> request
> >> >>>> >> > missing the cookie. We should also be able to
restrict
> >>external
> >> >>>> >>requests
> >> >>>> >> > just by listening on 127.0.0.1 instead of 0.0.0.0
(doesn't
> >>look
> >> >>>> >> > like GCDWebServer supports this, but we can hack
it in).
> >> >>>> >> >
> >> >>>> >> > The problem of port conflicts is annoying though.
Maybe we try
> >> >>>>random
> >> >>>> >> ports
> >> >>>> >> > until one works? Is there any need to use the
same port for
> >> >>>>multiple
> >> >>>> >> runs?
> >> >>>> >> >
> >> >>>> >> > The CORS thing is sad, because it also means
things like
> >>Camera
> >> >>>>plugin
> >> >>>> >> will
> >> >>>> >> > be broken (can't use resulting URL in <img>).
> >> >>>> >> >
> >> >>>> >> > Although we might just do (this is different
than the current
> >> >>>>mapping
> >> >>>> >>in
> >> >>>> >> > the plugin):
> >> >>>> >> > http://localhost:RANDOM_PORT/www
> >> >>>> >> > http://localhost:RANDOM_PORT/asset-library
> >> >>>> >> > http://localhost:RANDOM_PORT/file-system
> >> >>>> >> >
> >> >>>> >> > to proxy the three locations.
> >> >>>> >> >
> >> >>>> >> > This also means we can't use FileEntry.toURL()
and have it
> >>work,
> >> >>>> >>unless
> >> >>>> >> > toURL returns http://localhost:RANDOM_PORT/file-system/...
> >> >>>>Maybe
> >> >>>> >> that's
> >> >>>> >> > fine?
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> > I don't think it's weird that an app will need
to support
> >> >>>>WKWebView on
> >> >>>> >> some
> >> >>>> >> > OS versions, and UIWebView on others. That's
already the case
> >>to
> >> >>>> >>support
> >> >>>> >> > iOS 7.
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> >
> >> >>>> >> > On Wed, Oct 29, 2014 at 6:22 PM, Shazron <shazron@gmail.com>
> >> >>>>wrote:
> >> >>>> >> >
> >> >>>> >> > > This does not preclude using the file url
API function I
> >> >>>>suppose.
> >> >>>> >> Here's
> >> >>>> >> > a
> >> >>>> >> > > flowchart on how I think it would work:
> >> >>>> >>http://i.imgur.com/zq4zreN.png
> >> >>>> >> > >
> >> >>>> >> > >
> >> >>>> >> > > On Wed, Oct 29, 2014 at 2:48 PM, Tommy Williams
> >> >>>><tommy@devgeeks.org
> >> >>>> >
> >> >>>> >> > > wrote:
> >> >>>> >> > >
> >> >>>> >> > > > This whole thing reeks of sadness and
pain.
> >> >>>> >> > > >
> >> >>>> >> > > > The security implications of this will
have to be
> >>considered
> >> >>>>very
> >> >>>> >> > > > carefully.
> >> >>>> >> > > > On 29 Oct 2014 16:40, "Shazron" <shazron@apache.org>
> >>wrote:
> >> >>>> >> > > >
> >> >>>> >> > > > > ## What We Know So Far
> >> >>>> >> > > > >
> >> >>>> >> > > > > 1. Because of the file:// url
loading bug, we couldn't
> >> >>>>support
> >> >>>> >>the
> >> >>>> >> > > > > WKWebView in the iOS 8 GM release.
It has since been
> >>fixed,
> >> >>>>for
> >> >>>> >> > release
> >> >>>> >> > > > > post iOS 8.1 (not sure when),
through a new WKWebView
> >>API
> >> >>>> >>function
> >> >>>> >> (
> >> >>>> >> > > > > http://trac.webkit.org/changeset/174029/trunk)
> >> >>>> >> > > > > 2. The alternative is embedding
a local web server and
> >> >>>>serving
> >> >>>> >> assets
> >> >>>> >> > > > from
> >> >>>> >> > > > > that
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Abandon file:// url Loading
API Method
> >> >>>> >> > > > >
> >> >>>> >> > > > > My proposal is, we abandon the
local file:// url loading
> >> >>>>method
> >> >>>> >>in
> >> >>>> >> > (1)
> >> >>>> >> > > > > above, since it will create problems
with support.
> >> >>>> >> > > > >
> >> >>>> >> > > > > For example, if we support the
new local file url
> >>loading
> >> >>>>API
> >> >>>> >> > function
> >> >>>> >> > > in
> >> >>>> >> > > > > iOS 8.2.0 (speculated) -- and
a user is on 8.0.2, what
> >> >>>>then?
> >> >>>>You
> >> >>>> >> > would
> >> >>>> >> > > > not
> >> >>>> >> > > > > have WKWebView support for that
user, and you would use
> >> >>>> >>UIWebView
> >> >>>> >> > > > instead.
> >> >>>> >> > > > > This will just be confusing, and
leads to problems.
> >> >>>> >> > > > >
> >> >>>> >> > > > > With the embedded local web server
method, you can
> >>support
> >> >>>> >>**any**
> >> >>>> >> > > > version
> >> >>>> >> > > > > of iOS 8.x.
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Embrace Embedded Local Web
Server Method
> >> >>>> >> > > > >
> >> >>>> >> > > > > I have a Cordova plugin that implements
this, and it
> >>should
> >> >>>>work
> >> >>>> >> with
> >> >>>> >> > > > > cordova-ios 3.7.0:
> >> >>>> >> > > > > https://github.com/shazron/CordovaLocalWebServer
> >> >>>> >> > > > >
> >> >>>> >> > > > > It dynamically updates the <access>
tag value when it
> >> >>>>loads,
> >> >>>> >> > overriding
> >> >>>> >> > > > it
> >> >>>> >> > > > > to the actual location and port.
Since it is a plugin,
> >>it
> >> >>>>can be
> >> >>>> >> > > > swappable
> >> >>>> >> > > > > (for whatever reason).
> >> >>>> >> > > > >
> >> >>>> >> > > > > It does not solve the problem
where any backgrounded app
> >> >>>>can
> >> >>>> >>access
> >> >>>> >> > our
> >> >>>> >> > > > > local web server.
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Future Steps
> >> >>>> >> > > > >
> >> >>>> >> > > > > This plugin is already working
in cordova-ios 3.7.0
> >> >>>> >>(un-released,
> >> >>>> >> up
> >> >>>> >> > > next
> >> >>>> >> > > > > for vote release).
> >> >>>> >> > > > >
> >> >>>> >> > > > > The wkwebview branch:
> >> >>>> >> > > > >
> >> >>>> >> > > > > 1. Needs be rebased
> >> >>>> >> > > > > 2. Needs to be re-tested
> >> >>>> >> > > > > 3. issues in CB-7043 that relate
to the wkwebview have
> >>to
> >> >>>>be
> >> >>>> >> resolved
> >> >>>> >> > > > > 4. branch presented for review
to other committers
> >> >>>> >> > > > > 5. resolve any comments and issues
from (4)
> >> >>>> >> > > > > 6. wkwebview branch integrated
into master
> >> >>>> >> > > > >
> >> >>>> >> > > > > I will work on these items next
after getting
> >>cordova-ios
> >> >>>>3.7.0
> >> >>>> >> out.
> >> >>>> >> > > Any
> >> >>>> >> > > > > help is welcome.
> >> >>>> >> > > > >
> >> >>>> >> > > > > ## Migration Issues
> >> >>>> >> > > > >
> >> >>>> >> > > > > If you are migrating to WKWebView
from UIWebView, you
> >>will
> >> >>>>lose
> >> >>>> >> some
> >> >>>> >> > > > > functionality.
> >> >>>> >> > > > >
> >> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol
is not
> >> >>>>supported
> >> >>>>in
> >> >>>> >> > > > WKWebView)
> >> >>>> >> > > > > 2. Your XmlHttpRequest calls now
need to be CORS
> >>compliant
> >> >>>> >>(this is
> >> >>>> >> > > still
> >> >>>> >> > > > > true if loaded through a file://
url)
> >> >>>> >> > > > > 3. HTML5 offline application cache
is not available in
> >> >>>> >>WKWebView (
> >> >>>> >> > > > > https://devforums.apple.com/message/1060452)
> >> >>>> >> > > > >
> >> >>>> >> > > >
> >> >>>> >> > >
> >> >>>> >> >
> >> >>>> >>
> >> >>>>
> >> >>>>
> >> >>>>
> >>---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>>>
> >> >>>>
> >> >>>>
> >>---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>>>
> >> >>>>
> >> >>
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
>
>

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