Bug #3534
VNC viewer uses GET
Status: | New | Start date: | 01/30/2015 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | Sunstone | |||
Target version: | - | |||
Resolution: | Pull request: | |||
Affected Versions: | OpenNebula 4.10 |
Description
The Sunstone VNC viewer uses a GET request with all sensitive parameters in the URL when entering the full-screen VNC viewer (did not find this in the default web viewer that is windowed, but my proxy was having some issues with the initial websocket connection).
This is a significant security hazard. While the URL parameters are encrypted with TLS to the server, there are multiple unauthorized disclosures of the VNC password, host, port, and session token (which appears to not invalidate once the user logs out and the VNC session terminates, need to time it still).
There are a few places this causes a problem: first, in the browser's history the sensitive parameters are stored in cleartext and viewable in history. This is problematic for multi-user machines such as workstations, even more so in enterprise workstations where a shared machine may have the same browser profile for all users as a system rather than user profile. The workstation issue is less common, but history is never considered protected.
Next disclosure location is in log files. By using a GET request, logging systems can capture the credentials on any system that handles the traffic other than untrusted transit. This includes and HTTPS firewalls/proxies, SSL endpoints, and many other locations. While the systems that handle that traffic are usually trusted, the users who view diagnostic logs may not be (either error, or a logging infrastructure for sensitive systems). Even if sunstone is on the same machine as the logs, you can't assume the log viewer for such basic information as the path of a request will have permissions to maintain other components.
As well log files are usually expected to be sanitized except for debug files, and as such are often sent in the clear to a logging server or some monitoring system.
The recommended way to handle sending such information over the web is via POST, which is not data usually captured except by deep inspection loggers which are considered out of scope as they have to be manually configured for that purpose.
Since the VNC viewer is currently doing GET, a simple fix while determining a long term solution might be to modify the fullscreen mode to POST the data to a local machine session that passes it to VNC with the user token. While hacky, this would allow VNC viewer to start the session with the parameters and while the POST path will be logged, the sensitive data is not.
Related issues
History
#1 Updated by Ruben S. Montero over 6 years ago
- Priority changed from Normal to High
- Target version changed from Release 4.10.2 to Release 4.12
#2 Updated by Daniel Molina over 6 years ago
- Assignee set to Daniel Molina
#3 Updated by Daniel Molina over 6 years ago
- Status changed from Pending to New
- Assignee deleted (
Daniel Molina) - Target version deleted (
Release 4.12)
#4 Updated by Daniel Molina over 5 years ago
- Related to Feature #4145: Request vnc password when the vnc session is opened in an external window added