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" <shaz...@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.ho...@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.ho...@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.ho...@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" <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 >> >>>> >> >>>> >> >> >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >>
