Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates
 209.85.213.169 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: <D07CF94E.28E40%tony.homer@intel.com>
References: 
 <CAE6O_-aBHmyw6SKVHuuUZCxYaiaK4v2qh8401K2-SbtPtgm+7w@mail.gmail.com>
 <CAPTyS6DtkdNkkDGVe5bAwRTXUsBK7w_WHa4NDV4Rkrdf9uAQfA@mail.gmail.com>
 <CAE6O_-YsR9CN2GO8T6kkL13EzpQk4HhALV83wi4SKmz9qfFiMg@mail.gmail.com>
 <CABiQX1V7Y18-n=L97S+rwgNH_cMR0GWV4wm0JQ9FGs_1ty_E4g@mail.gmail.com>
 <CAE6O_-b9KCx6Snqj=OLWDnAG=HS9Mww9xj_RA0QnHqBC90Dx4g@mail.gmail.com>
 <CABiQX1U-J6vayb2n9_xadZFy+CSAWX632uQ1mXppjy=VvXDH+w@mail.gmail.com>
 <D07921A4.28A90%tony.homer@intel.com>
 <ee6b66acd95842f5b2e00537e9bf70e8@BL2PR03MB129.namprd03.prod.outlook.com>
 <CABiQX1U3-HjVk=wyApnTMZAkAzv9badn1oxJxaq1i3QJV-zHKQ@mail.gmail.com>
 <D0794422.28B41%tony.homer@intel.com> <D07ABA05.28D9E%tony.homer@intel.com>
 <D07CF94E.28E40%tony.homer@intel.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Mon, 3 Nov 2014 10:46:59 -0500
Message-ID: 
 <CAEeF2TctD3ZYW8iX6uqCmsJOCNALrzNTkYJt9FrSeSZdYWDgMw@mail.gmail.com>
Subject: Re: [iOS 8] WKWebView moving forward
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a113fdfd40a60820506f6438d

--001a113fdfd40a60820506f6438d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Awesome analysis Tony, thanks for the efforts & the great summary.

On Mon, Nov 3, 2014 at 10: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 ar=
e
> not practical were:
> 1. unique token per http request - not practical because there is no per
> http request event available
> 2. a whitelist of =E2=80=9Cremote=E2=80=9D 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 =E2=80=9Cattacks=E2=80=
=9D 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 o=
n
> device
>
> Therefore, vulnerability is limited to the case where the there is
> (1) a =E2=80=9Chostile" app installed on device and running in the backgr=
ound and
> (2) the user=E2=80=99s device is connected to a wi-fi network where an at=
tacker 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 =E2=80=9Chostile wifi network=E2=80=9D 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 t=
he
> >file:// requests.
> >However, WKWebView does not offer a way to intercept resource requests s=
o
> >that won=E2=80=99t 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 t=
he
> >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 th=
at
> >bothers me, is that now those core plugins effectively support a non-cor=
e
> >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 =E2=80=93 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 fil=
e
> >and should allow other non-cordova plugins that depend on file:// URLs t=
o
> >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=E2=80=99t think of a way to avoid replay vulnerability with co=
okies
> >>(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=
=E2=80=99m
> >>not a security guy, so I wasn=E2=80=99t sure if it mattered or not. Tha=
t=E2=80=99s
> >>actually one of the things I was hoping to get feedback about.
> >>
> >>I guess I don=E2=80=99t follow how CORS relates to the camera plugin, d=
oes it use
> >>XHR? Maybe you can elaborate?
> >>I expect I=E2=80=99ll see it when I try the camera plugin from WKWebVie=
w, just
> >>didn=E2=80=99t 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=E2=80=99s jus=
t a path
> >>problem, maybe we could intercept the request, fix the path, then respo=
nd
> >>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-focuse=
d
> >>>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 t=
o
> >>>>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=C2=B9m going to investigate adding a map to the plugin, then add a=
n entry
> >>>>for
> >>>> every request.
> >>>> The entry will be a hash of the request and a random number.
> >>>>
> >>>> I=C2=B9ll 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 remov=
e
> >>>>it -
> >>>> this should eliminate re-playability.
> >>>>
> >>>> I=C2=B9m not sure about the CORS issue with camera plugin=C5=A0 I=C2=
=B9ll be curious
> >>>>to
> >>>> test it - maybe it could be addressed by modifying the response in t=
he
> >>>> GCDWebServer handler?
> >>>>
> >>>> Tony
> >>>>
> >>>> P.S. This is my first attempt participating in discussion on the lis=
t
> >>>>-
> >>>> let me know if I=C2=B9m 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 versi=
on
> >>>> >>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 ht=
tp
> >>>> >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 t=
o
> >>>> >>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 considere=
d
> >>>>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 fixe=
d,
> >>>>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 suppor=
t
> >>>> >>**any**
> >>>> >> > > > version
> >>>> >> > > > > of iOS 8.x.
> >>>> >> > > > >
> >>>> >> > > > > ## Embrace Embedded Local Web Server Method
> >>>> >> > > > >
> >>>> >> > > > > I have a Cordova plugin that implements this, and it shou=
ld
> >>>>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 wil=
l
> >>>>lose
> >>>> >> some
> >>>> >> > > > > functionality.
> >>>> >> > > > >
> >>>> >> > > > > 1. No more whitelist feature (NSURLProtocol is not
> >>>>supported
> >>>>in
> >>>> >> > > > WKWebView)
> >>>> >> > > > > 2. Your XmlHttpRequest calls now need to be CORS complian=
t
> >>>> >>(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
>

--001a113fdfd40a60820506f6438d--