- From: Brad Hill <hillbrad@gmail.com>
- Date: Thu, 19 Mar 2015 18:43:13 +0000
- To: Devdatta Akhawe <dev.akhawe@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAEeYn8jdu=k=Hyzd6b+F2oJozBuWjOM_kW-K1d7UMeNwyLxFgw@mail.gmail.com>
There's also the abuse case seen in the wild of Android apps deliberately listening on localhost, and web pages using that to get permissions the app has, but which the web page does not. (e.g. geolocation) On Thu, Mar 19, 2015 at 1:49 AM Devdatta Akhawe <dev.akhawe@gmail.com> wrote: > Hi > > In https://code.google.com/p/chromium/issues/detail?id=378566, the > blink team is planning on blocking all connections to private networks > and localhost. This is unfortunate, because (as discussed in the bug) > this breaks a bunch of applications. I was wondering: instead of > cutting down all accesses outright, can we make a compromise in > allowing websockets to connect? > > The websocket handshake is designed to not mistakenly allow access: > instead, there are specific steps the servers have to take to agree to > connect over websockets and so I don't see much security hardening > achieved by blocking websockets. What do others think? (I am not sure > this is even under the purview of w3c since I don't believe "block > private networks" is a standard). > > Additionally, I think browsers should also allow websocket connections > to localhost in a secure context because the browser can ensure that > this never left the computer to get on the (untrusted) network. This > part 2 definitely seems like part of MIX. > > cheers > Dev > > full disclosure for those who didn't read the bug: Dropbox (my current > employer) is also affected by this issue. That said, these opinions > are mine and do not represent my employer's. > >
Received on Thursday, 19 March 2015 18:43:40 UTC