To add to that, I'd bet that most serious deployments of guacamole are putting it behind nginx or some other proxy and/or load balancer. The cookies allow the backend to control and isolate guacamole sessions or deployments. This is really useful. For large-scale deployments this has to be a must-have feature. The vulnerability is an interesting point, I had actually noticed that the Secure flag was missing too and was adding it manually with an nginx rule. It is not an inherent flaw of cookies though. The rest of the world wide web does cookie-based authentication for a reason. Storing everything in localstorage means that the backend has no control.
Lee, since you're having this same problem, I can share my stop gap solution. LocalStorage is isolated based on SameOrigin policy, so https://a.example.com and https://b.example.com don't share LocalStorage. If you are able to issue wildcard https certs (LetsEncrypt can do it) and configure your nginx/proxy to match locations with an appropriate regex, then you can achieve session isolation with subdomains. I would really appreciate if a prefixing/pathing solution was defined for the LocalStorage entries though because subdomains are not always possible to use. ________________________________ From: Lee <[email protected]> Sent: Monday, March 4, 2019 4:04 PM To: [email protected] Subject: Re: 1.0.0 LocalStorage auth instead of cookies My issue (and need for Cookie-based auth or an alternative) is very similar. Lev noted this in my own thread and pointed here. In my case, we determined that our users only needed the servers for a few hours and different times of the week or month so we generally have the virtual machines off. We also determined that Guacamole probably not the best system to control spinning up or down these virtual machines -- designing the extensions would have been difficult, and prone to issues as guacamole matured. So we designed a wrapper that is responsible for ensuring the servers are available when the users need them; The users start the system outside guacamole, and get a button that opens a new tab with a one-time-use cookie that drops them directly into the specified server on demand. To reduce any confusion, we strip away most of the guacamole client features like user management, and let guacamole handle the RDP/SSH sessions through 'just-in-time' configurations provided by our authentication extension, which can also pass in configuration options. Guacamole effectively persists nothing outside sessions. The clearing of cookies in the past caused no issues on existing sessions, so a user could have 4 tabs with different RDP/SSH sessions at the same time (or, in some cases, sessions to the same server that was configured to give new SSH/RDP sessions for each connection). We found this very valuable -- such as teachers looking at or troubleshooting multiple student sessions at the same time. It's also helpful when working on an exercise that has two computers talking to each other. With out testing and approach, these sessions could go on nearly indefinitely, even if their cookies were destroyed. Survival through a tab refresh is not a requirement for us. Incognito mode is a good work-around for technical people, but not a great workaround for elementary and middle school students (or teachers) who are using the guacamole service in their "Introduction to computers" class. Does this give a possible use case for cookie-based authentication? My team's plan is to destroy the local storage data as well as the cookies and see if that allows us to move forward. Hopefully it allows sessions to persist like it has in the past. -Lee Virginia Tech / Virginia Cyber Range -- Sent from: https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-guacamole-general-user-mailing-list.2363388.n4.nabble.com%2F&data=02%7C01%7C%7C2d8c819cccb34059bbb408d6a0fe1cf6%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636873410591514300&sdata=WCelKE6X8yyDl2FZaBv%2Bk0F1IaZIAgLUinDjF%2FgKkUs%3D&reserved=0
