On Wednesday, June 21, 2017 at 1:35:13 PM UTC-5, Matthew Hardeman wrote: > Regarding localhost access, you are presently incorrect. The browsers do not > allow access to localhost via insecure websocket if the page loads from a > secure context. (Chrome and Firefox at least, I believe do not permit this > presently.) I do understand that there is some question as to whether they > may change that.
Right, I wasn't taking about WebSockets in particular, but about any possible form of direct communication between the web app and desktop application. That's why I pointed to plain old HTTP requests as an example. > As for whether or not access to localhost from an externally sourced web site > is "inherently a bad thing". I understand that there are downsides to > proxying via the server in the middle in order to communicate back and forth > with the locally installed application. Having said that, there is a serious > advantage: > > >From a security perspective, having the application make and maintain a > >connection or connections out to the server that will act as the > >intermediary between the website and the application allows for the network > >administrator to identify that there is an application installed that is > >being manipulated and controlled by an outside infrastructure. This allows > >for visibility to the fact that it exists and allows for appropriate > >mitigation measures if any are needed. > > For a website to silently contact a server application running on the > loopback and influence that software while doing so in a manner invisible to > the network infrastructure layer is begging to be abused as an extremely > covert command and control architecture when the right poorly written > software application comes along. I guess I don't completely understand what your threat model here is. Are you saying you're worried about users installing insecure applications that allow remote code execution for any process that can send HTTP requests to localhost? Or are you saying you're concerned about malware already installed on the user's computer using this mechanism for command and control? Both of those are valid concerns. I'm not really sure whether they're significant enough though to break functionality over, since they both require the user to already be compromised in some way before they're of any use to attackers. Though perhaps requiring a permissions prompt of some kind before allowing requests to localhost may be worth considering... As I said though, this is kinda straying off topic. If the ability of web apps to communicate with localhost is something that concerns you, consider starting a new topic on this mailing list so we can discuss that in detail without interfering with the discussion regarding TLS certificates here. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
