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

Reply via email to