Use hash fragment to supply parameters instead of query string

[ganeshv]

For privacy, it is better to supply parameters like host and port in the hash fragment rather than the query string. The query string is visible to the server which hosts the noVNC HTML/JS and intermediate proxies, while the hash fragment is not. Javascript can as easily use the hash fragment as the query string as a source of parameters.

I'm developing a VNC backend for Qt 5, where one can run a Qt 5 app headless, connect to it on a browser http://app.host:5900 which redirects to http://novnc.host/qtvnc.html#host=app.host&port=5900

I have modified my noVNC fork to to take parameters in the hash fragment. You can see the code here.

[kanaka]

@ganeshv I'm not sure how useful that is host/port, but certainly for token or password I can see why that would be desirable. Adding that as an optional way to provide variable values is fine with me. Please send a PR with just that part (not the qtvnc) portion.

[ganeshv]

@kanaka IMHO, from a security and privacy standpoint, the less information leaked the better, even if we have no idea how it might be exploited. host/port leaks the location of a live VNC server to whoever is hosting the viewer, and to all intermediate proxies and CDNs. In case of no password, or a weak/known password, this makes it easier for an intermediary to snoop on a VNC session. This is especially avoidable since it is not technically absolutely necessary.

I have made a first pass at coding this up. Any config variable may be present either in the query string or hash fragment, with the hash fragment being preferred in case they are present in both.

Let me know if this approach looks OK and I will dot the i's and submit a pull request.

[kanaka]

@ganeshv Yes, providing the option for noVNC integrators to avoid leaking host/port (or any other config variable) is fine and I support that.

However, I should point out it's not the host/port of the VNC server that is leaked, it's the host/port of the websocket/websockify server. Most integrators will be using the tokenfile plugin (or something similar) to switch between backend VNC targets and not connecting to anything without a token. As long as the tokens are opaque/strong and recreated for each connection, there really isn't much info that is leaked except the websocket address. Having the token in the hash will certainly help with certain attacks (e.g. replay), but hiding the host/port (which point to an open port on the Internet) should not be relied on since that can be discovered/predicted by other means (port scan, MitM).

Your approach looks fine. Don't forget the getQueryVar references in include/ui.js too.