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" <agri...@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.sh...@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.ho...@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" <agri...@chromium.org> wrote: >> >> >On Thu, Oct 30, 2014 at 5:05 PM, Shazron <shaz...@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 <agri...@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 <shaz...@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 >><to...@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" <shaz...@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-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>
