In this document, I will describe the security features of httpvnc in version 1.7
User Interaction Points
The following user interaction points exist, where a security breach may be possible:
- the desktop session itself, where users are logged in and might want to hijack or monitor sessions of other users by Unix means
- the webserver (web interface) may be attacked from outside in order to gain access to single or multiple user accounts
- the websocket handler (HTML5 canvas interface) may be attacked from outside in order to hijack running sessions
- the directconnection handler (Java applet interface) may be attacked from outside in order to hijack running sessions
- the onetime connection web interface may be attacked from outside in order to hijack running sessions
- the broker interface may be attacked locally from a running desktop session, or by another service in order to be able to control every aspect of httpvnc
Desktop Session Security
- Any user running a desktop session must be member of the group httpvnc, so the administrator of a system can decide who is trustworthy enough.
- The directory /tmp/httpvnc, where all session access points (socket files) are located, is not readable for anyone else than root and the webserver user. This makes it impossible to harvest session ids (which would be disastrous otherwise).
Web Interface Security
The web interface is secured by three means:
- All communication is SSL tunnelled.
- Any user connected to the web interface must have a session id stored in a cookie. The cookie is generated on initial connect to the interface and requires authentication with username and password.
- Once a user has a valid session cookie, he must know the id of a session in order to handle it. The web interface will only provide the session ids belonging to the specific user. Any action taken over the web interface will first check if the session id provided belongs to this user.
- Each web interface session is associated with an IP. No session cookie from a wrong IP is accepted. If too many failed login attempts originate from one IP, this IP is banned for a period of time.
Websocket Security
The websocket is used by the HTML5 canvas object.
- All communication is SSL tunnelled.
- Any desktop session id used in the websocket interface must first be mapped by the webserver (and this mapped id may be used in order to connect to the websocket). This mapping is valid only for a short period of time. This means that in order to connect to a websocket session, the user must first get a temporary id from the web interface. Please note that these temporary id mappings have little to nothing in common with the onetime ids. This makes session keys stored in browser cache files or visible in the website code effectively useless after a very short period of time, thus almost entirely disabling replay attacks.
Directconnect Security
The direct connect interface is used by the Java applet. It is basically a handler that converts an existing http stream into a VNC stream.
- Any desktop session id used in the directconnect interface must first be mapped by the webserver (see above for an explanation).
- Too many failed session tries will ban the IP for a period of time
- Connections must originate from an IP that had a successful web interface connection recently.
Onetime Security
- All communication is SSL tunnelled.
- Any id used as a onetime id is valid only once.
- Valid onetime ids should be hard to come by.
Broker Security
The session broker may be connected to over the Unix socket /var/run/httpvnc.sock.
- Connections are possible only from the local machine
- Connections are only allowed for root and any member of httpvncd (not the same group as httpvnc!), of which only the webserver and other management interfaces should be member. Never put any httpvnc users in this group!
- Session ids may be retrieved only after successful authentication with username and password (which are not known even to the webserver or anyone else but the respective user). However, onetime ids are available always, so after all the only thing standing between a secure and a completely insecure httpvnc system is really the fact that only httpvncd members may connect to the session broker.