I am not sure if this is a valid concern. If I am using a CLI and someone gets access to my computer, they can do whatever they well please. If I am using Horizon and someone gets access, its going to be the same story, they can still do damage even without knowing the token (at least until the web session or token expires). This is just the nature of using token-based authentication, if someone steals it, they will get access for a brief time to do whatever they want. So the notion that hiding the token from the front-end is somehow going to make it safer does not make sense to me.
----- Original message -----
From: Timur Sufiev <tsuf...@mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Cc:
Subject: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client
Date: Wed, Jun 29, 2016 2:11 PM
Hello, vigilant folks of OpenStack Security team!The commit(s) I'd like you to take a look at introduces a new Horizon feature, Create (Glance) Image using CORS (AKA Cross-Origin Resource Sharing) [1].The main idea is to bypass Horizon web-server when uploading large local image and to send it directly to Glance server, thus saving network bandwidth and disk space on the controller node where Horizon web-server is deployed. However there is one possible security trade-off I had to make so that Glance service would allow me to upload an image - I'm passing the Keystone token to the Horizon JS runtime [2], and then pass it to Glance service [3] or [4] (different links here correspond to different versions of new Create Image - Django and Angular). This trade-off made Horizon community somewhat hesitant if we should push these changes forward, but nobody yet voiced a viable alternative, so here I'm writing this letter to you.The usual Horizon workflow for working with Keystone tokens is the following: retrieve scoped token and put it into web-server session, which is itself not exposed to browser (unless SESSION_STORAGE signed_cookies backend was chosen, but even in that case session contents are encrypted in some way), but is kept on web-server and referenced using the session key which is kept in browser cookies - so one may say that in existing setup keystone token never leaks to browser.On the other hand, in some not so far (I hope) future, when more logic is moved to client-side UI (i.e. browser), the issue of browser authenticating to some OpenStack services directly would become more widespread, it just happened that this work on Create Image in Horizon is pioneering this area (AFAIK). So, what do you think of possible security implications of this setup?Just for the reference, three patches mentioned in [1-3] implement most of the logic of new Create Image feature.__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
