On Wednesday, June 21, 2017 at 12:41:53 PM UTC-5, andre...@gmail.com wrote:
> I feel like this is getting sort of off-topic. Web pages can communicate > directly with applications on the local machine regardless of whether they > abuse certificates in this way or not. (Such as, for example, by using plain > old HTTP.) The question of whether or not they should be able to do that is a > separate topic IMO. > > Certificate abuse aside, I disagree with your assertion that this is > inherently a bad thing. Even if browsers were to block web apps from > communicating with localhost, they could still achieve pretty much the same > thing by using an external server as a proxy between the web app and the > locally installed application. The only major difference is that with that > method they'd be using unnecessary internet bandwidth, introducing a few > dozen extra milliseconds of latency, and would be unable to communicate > offline - all downsides IMO. If you _really_ want to try blocking this > anyway, you could always use a browser extension. Certificate abuse aside, I suppose I have diverged from the key topic. I did so with the best intentions and in an attempt to serve to respond directly to the questions raised by the initiator of this thread as to the use case and how best to achieve the use case indicated. 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. 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
