Awesome analysis Tony, thanks for the efforts & the great summary. On Mon, Nov 3, 2014 at 10: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 >
