I suspect that thread didn't get much attention because of missing [Horizon] tag. Added it.
To me, using signed cookies session backend as default one is not only prone to security vulnerabilities, but also will someday hit the 4096 bytes cookie-limit per domain. Are there some serious reasons to keep it as default session backend? On Fri, Jun 20, 2014 at 7:33 PM, Nathan Kinder <nkin...@redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Session-fixation vulnerability in Horizon when using the default > signed cookie sessions > - --- > > ### Summary ### > The default setting in Horizon is to use signed cookies to store > session state on the client side. This creates the possibility that if > an attacker is able to capture a user's cookie, they may perform all > actions as that user, even if the user has logged out. > > ### Affected Services / Software ### > Horizon, Folsom, Grizzly, Havana, Icehouse > > ### Discussion ### > When configured to use client side sessions, the server isn't aware > of the user's login state. The OpenStack authorization tokens are > stored in the session ID in the cookie. If an attacker can steal the > cookie, they can perform all actions as the target user, even after the > user has logged out. > > There are several ways attackers can steal the cookie. One example is > by intercepting it over the wire if Horizon is not configured to use > SSL. The attacker may also access the cookie from the filesystem if > they have access to the machine. There are also other ways to steal > cookies that are beyond the scope of this note. > > By enabling a server side session tracking solution such as memcache, > the session is terminated when the user logs out. This prevents an > attacker from using cookies from terminated sessions. > > It should be noted that Horizon does request that Keystone invalidate > the token upon user logout, but this has not been implemented for the > Identity API v3. Token invalidation may also fail if the Keystone > service is unavailable. Therefore, to ensure that sessions are not > usable after the user logs out, it is recommended to use server side > session tracking. > > ### Recommended Actions ### > It is recommended that you configure Horizon to use a different session > backend rather than signed cookies. One possible alternative is to use > memcache sessions. To check if you are using signed cookies, look for > this line in Horizon's local_settings.py > > - --- begin example local_settings.py snippet --- > SESSION_ENGINE = 'django.contrib.sessions.backends.signed_cookies' > - --- end example local_settings.py snippet --- > > If the SESSION_ENGINE is set to value other than > 'django.contrib.sessions.backends.signed_cookies' this vulnerability > is not present. If SESSION_ENGINE is not set in local_settings.py, > check for it in settings.py. > > Here are the steps to configure memcache sessions: > > 1. Ensure the memcached service is running on your system > 2. Ensure that python-memcached is installed > 3. Configure memcached cache backend in local_settings.py > > - --- begin example local_settings.py snippet --- > CACHES = { > 'default': { > 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache', > 'LOCATION': '127.0.0.1:11211', > } > } > - --- end example local_settings.py snippet --- > > Make sure to use the actual IP and port of the memcached service. > > 4. Add a line in local_settings.py to use the cache backend: > > - --- begin example local_settings.py snippet --- > SESSION_ENGINE = 'django.contrib.sessions.backends.cache' > - --- end example local_settings.py snippet --- > > 5. Restart Horizon's webserver service (typically 'apache2' or > httpd') > > Furthermore, you should always enable SSL for Horizon to help mitigate > such attack scenarios. > > Please note that regardless of which session backend is used, if the > cookie is compromised, an attacker may assume all privileges of the > user for as long as their session is valid. > > ### Contacts / References ### > This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0017 > Original LaunchPad Bug : https://bugs.launchpad.net/horizon/+bug/1327425 > OpenStack Security ML : openstack-secur...@lists.openstack.org > OpenStack Security Group : https://launchpad.net/~openstack-ossg > Further discussion of the issue: > http://www.pabloendres.com/horizon-and-cookies/#comment-115 > Django docs: > https://docs.djangoproject.com/en/1.6/ref/settings/ > > https://docs.djangoproject.com/en/1.6/topics/http/sessions/#configuring-sessions > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTpFQ7AAoJEJa+6E7Ri+EVuO8IAJvfqVZOHaC0zWwpQiaHBnLg > RCtlUdSQgPR/wLhWsKjOK9swMC0ajue8hwDKuo4bzpzTEHkC0hswCTkcENaxO0f5 > 7uZisx/FYtdvD+IqoRjOaS23klyNOe8xTwbitsDCqgEZUyLJPAzgN+KiAwcXaoQC > UyAOMuRZgywKjGQDLGPiUrR2ug604FBmfxzywvE3iiCaNi/+4vdcHSr9wyNtzKDH > g9zM861eCbDfDP9rUzpPytNVt5H5QXLGrUl9/+M6BN2a13RpC5dRxQfP5OlgYlSy > 3LiqSogFn5naC/eF7rR/kFVKfgf7FN0e9zS9ZSqFfXevZSAIY9cEP7E0V5XtyfY= > =FDu2 > -----END PGP SIGNATURE----- > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Timur Sufiev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev