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 Fri, 31 Oct 2014 18:03:48 GMT
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
>>
>>

Mime
View raw message