Open Stack

Hi David,

How do you feel about the approach here:
https://review.openstack.org/#/c/311189/

Its lets the existing angular js module:
horizon.app.core.openstack-service-api.keystone

access the current token via getCurrentUserSession().token

Thanks,
Kevin
________________________________________
From: David Stanek [dstanek at dstanek.com]
Sent: Friday, July 01, 2016 11:17 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

On 06/29 at 21:10, Timur Sufiev wrote:
> 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.
>
> [1]
> https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
> [2]
> https://review.openstack.org/#/c/317365/15/openstack_dashboard/api/glance.py@215
> [3]
> https://review.openstack.org/#/c/230434/37/horizon/static/horizon/js/horizon.modals.js@212
> [4]
> https://review.openstack.org/#/c/317456/16/openstack_dashboard/static/app/core/openstack-service-api/glance.service.js@151

Since tokens are bearer tokens any leak could possibly lead to a
security issue. I don't see allowing the JS application to have access
to the token as being a terrible thing.

We just need to make sure we do it as safely as we can in order to
prevent the token from lingering around after the web session has
completed. For example, putting the token in redirect URLs may cause
it to end up in browser history, putting it in the source of page
that could be cached may write it to disk, etc, etc.

--
David Stanek
web: http://dstanek.com
blog: http://traceback.org

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev