On 21/06/2017 22:01, andrewm....@gmail.com wrote:
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.
The most obvious concern to me is random web servers, possibly through
hidden web elements (such as script tags) gaining access to anything
outside the Browser's sandbox without clear and separate user
action. For example, if I visit a site that carries an advertisement
for Spotify, I don't want that site to have any access to my locally
running Spottify software, its state or even its existence.
The most obvious way to have a local application be managed from a local
standard web browser while also using resources obtained from a central
application web site is for the local application to proxy those
resources from the web site. Thus the Browser will exclusively be
talking to a localhost URL, probably over plain HTTP or some locally
generated localhost certificate, that may or may not be based on
existing machine certificate facilities in some system configurations.
In other words, the user might open http://localhost:45678 to see the
App user interface, consisting of local element and some elements which
the app backend might dynamically download from the vendor before
serving them within the http://localhost:45678/ URL namespace.
This greatly reduces the need for any mixing of origins in the Browser,
and also removes the need to have publicly trusted certificates revealed
to such local applications.
For some truly complex scenarios, more complex techniques are needed to
avoid distributing private keys, but that's not needed for the cases
discussed here.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
