cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Homer, Tony" <tony.ho...@intel.com>
Subject Re: [iOS 8] WKWebView moving forward
Date Tue, 04 Nov 2014 02:55:12 GMT
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
View raw message