[OSSA 2014-040] horizon login page is vulnerable to DOS attack (CVE-2014-8124)

[Eric Peterson]

We have horizon deployed with mysql sessions. I believe this issue exists with all db backed sessions, and likely memchached too (but I am not sure).

Every request to the login page is generating a new session record in the db. This is based upon this line of code:
https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L41
What happens is as soon as you access request.session['foo'] then you are going to get an entry in the db.

I have placed some debugging code in a variety of locations where we are accessing the session store before we should be, which creates these records:

https://github.com/openstack/horizon/blob/master/horizon/middleware.py#L94
The check for the timeout should never occur if there is no authenticated user. So the check a few lines below needs to be moved higher.

https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/utils.py#L50
This check I am not sure how to work around. We are accessing the session, which creates records, just trying to keep track if a user is logged in or not. It seems like we are not using the django auth mechanisms correctly here, and I can't see if there is a workaround.

[Eric Peterson (ericpeterson-l)]

https://github.com/openstack/horizon/blob/master/openstack_dashboard/views.py#L45

Also contributes to this issue.

[Eric Peterson (ericpeterson-l)]

both the session clear and the set_test_cookie will cause a new session record to be created (fyi)

[Eric Peterson (ericpeterson-l)]

A good overview / description is in this thread:
http://stackoverflow.com/questions/4444758/huge-django-session-table-normal-behaviour-or-bug

[Tristan Cacqueray (tristan-cacqueray)]

Thanks for the report. This sounds like a bug with potencial security consequence, so I've added an incomplete security advisory task and subscribed Horizon's core security reviewers to comment.

How many extraneous sessions are created that could have been avoided ?

[Eric Peterson (ericpeterson-l)]

There is one session created for each request to horizon. So if you created a script to perform a bunch of curl requests to horizon, each curl requests gets a record in the db.

I found this with load balancer health checks, which occur fairly frequently. We had about 1,000 records within an hour for each instance of horizon for a conservative load balancer check. If I wanted to, I would expect I could create many more than this.

If I add extra django settings to cap the cookie age and a cron job to clean up these records, it is possible to somewhat limit the severity of what impact such health checks have so that the number does not grow much past our 1,000 per horizon instance. However, if a user wants to be malicious there is really a high ceiling of damage that can be done (especially with default settings from horizon and django).

[Lin Hua Cheng (lin-hua-cheng)]

For the service health check, it would probably be better to create a separate page that doesn't call set_test_cookie() method as describe here: http://stackoverflow.com/questions/17098142/django-session-created-in-database-when-login-page-loaded?lq=1

We can add that separate page in Horizon that is used just to check if Horizon is serving pages. Thoughts?

To summarize, seems there are three issue here that causes session to be created in the login page:
1. setting user object in the request:
https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/utils.py#L50

Once the request.user is accessed it will trigger a read on the SESSION for the session_key to get the user_id, then from the user_id fetch it in the backend. Seems like there is no way around checking if there is an authenticated user or not without hitting a read on the Session.

2. middleware that check session timeout: https://github.com/openstack/horizon/blob/master/horizon/middleware.py#L94

Even if we moved the check for authenticated user before timeout checking, this will still create a session because the middleware is going to call request.user.is_authenticated() - see #1.

3. set_test_cookie and session clear: https://github.com/openstack/horizon/blob/master/openstack_dashboard/views.py#L45

set_test_cookie is getting deprecated in the Login form for Django 1.7. It is suggested to just use CSRF protected view. We have a CSRF middleware that does a blanket protection on all pages, perhaps we can just remove it?

Django 1.7 deprecation notes (https://docs.djangoproject.com/en/dev/internals/deprecation/): "The undocumented check_for_test_cookie method in AuthenticationForm will be removed following an accelerated deprecation. Users subclassing this form should remove calls to this method, and instead ensure that their auth related views are CSRF protected, which ensures that cookies are enabled."

Even if we fix #3, we still have the same problem due to #1 and #2. I think any application can be targetted with DOS attack by just sending too many requests from a malicious attacker. For example other services have rate limiting in place to prevent that, it would be up to the operator to put the security in place to detect the attack.

I am not sure if we can really do anything about it, other than providing a health check page that won't create sessions everytime it is hit.

[Eric Peterson (ericpeterson-l)]

This patch resolves the issue, tested with MySQL backend.

It delays access to the session until a user has been authenticated.

[Eric Peterson (ericpeterson-l)]

This patch has minor corrections for unit tests and pep8 issues.

I believe this should be the final fix.

[Eric Peterson (ericpeterson-l)]

Correction to pydocs requested by Lin Hua Cheng.

[Lin Hua Cheng (lin-hua-cheng)]

patch LGTM, will wait for other cores to review.

[David Lyle (david-lyle)]

There is no need to create the session for unauthenticated requests.

The patch looks good to me. I think there is a potential need for a health check URL, but that seems to be a greater OpenStack need to arrive at a consistent mechanism for doing health checks.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks David for confirming the bug on Horizon project!

Now for the OSSA part, should we keep this under embargo and does this qualify as a DOS attack vector ?

Considering there is no amplification and that one connection results in one database entry I would triage this as class D bug (according to our new taxonomy described here: https://wiki.openstack.org/wiki/Vulnerability_Management#Incident_report_taxonomy )...

Thought ?

[Paul McMillan (paul-mcmillan)]

This bug can be trivially used to knock over any existing production deployment of Horizon that doesn't use cookie-based sessions.

There is no amplification, but I suspect I can break most production deployments to the point that fixing requires manual intervention in less than 30 minutes. I'd prefer not to make that public without also providing a fix.

I'd argue we should probably treat that as A or B1.

[Tristan Cacqueray (tristan-cacqueray)]

Apparently that bug lets you fill the DB much faster than expected. Thus we'll threat this as a class A.

The proposed patch apply cleanly on master and juno branch but it requires a bit of rework for Icehouse. Can someone provide a patch for Icehouse ?

Here is the proposed impact description #1. Note that I've considered all backends as vulnerable:

Title: Horizon denial of service attack through login page
Reporter: Eric Peterson (Time Warner Cable)
Products: Horizon
Versions: up to 2014.1.3 and 2014.2

Description:
Eric Peterson from Time Warner Cable reported a vulnerability in Horizon. By doing repeated requests to Horizon login page a remote attacker may generate unwanted session record resulting in a denial of service. All Horizon setups are affected.

[Lin Hua Cheng (lin-hua-cheng)]

I'll work on backporting the patch for Icehouse

[Tihomir Trifonov (ttrifonov)]

With the added check for:

    if settings.SESSION_COOKIE_NAME in request.COOKIES:

an attacker can easily set some fake cookie with the specified name, and will go through the session.create() anyway.

Regarding the get_user monkey patch - since we use external auth system(Keystone), we can't use the Django UserId, so we need to store Keystone User Id and SessionBackend in session, to create user from it.

One possible solution is to clean the session on line 59:

https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/utils.py#L59

But this way - although we will keep clear the database, we might end up with DOS vulnerability for the CREATE-DELETE DB requests on each anonymous request.

Another way is to monkey patch the load() method of SessionStore to avoid creation of a new session, since we do not use the session for anonymous requests.

[Eric Peterson (ericpeterson-l)]

If you get into the auth layer of the code and are assigning users to the request, that will create a session record no matter what (from what I have seen). In addition, I do not believe it is the responsibility of the auth package to perform maintenance on the session backend.

It is a very good point that the attacker could add a local cookie to try to fake out a valid session. However, the attacker would need to know the name of the session cookie id (which we could change I suppose from the default) and they would also have to keep on generating new session ids for each request. This is not a difficult task for an attacker, but it does become harder to attack with this approach.

The other part of this is that we need to add the config setting for:
https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SESSION_COOKIE_AGE
If we make this setting something more reasonably close to a typical keystone token lifespan, this issue becomes less severe. This setting can be combined with a cron job to run:
https://docs.djangoproject.com/en/dev/ref/django-admin/#django-admin-clearsessions

So if a keystone token is typically generated with a 1 hour lifespan, setting the cookie age to 1 hr and running the cron job every hour keeps the db as clean as possible.
(something like the info above might need to be included in a bug disclosure)

[Eric Peterson (ericpeterson-l)]

Tihomir Trifonov and I have agreed that there are ways to improve DOA as well with this issue.

The horizon fix seems ok / good, but there is likely some DOA fixes to help improve this issue as well.

[Tristan Cacqueray (tristan-cacqueray)]

@Eric Well the attack vector remains if adding a fake cookie trigger the extra session creation.
And the one hour timeout proposed seems to big according to comment #13 assumption where only 1/2 hours is required to overwhelm the service...

How about the monkey patch of SessionStore.load method, wouldn't it be easer to implement ?

[Eric Peterson (ericpeterson-l)]

@Tristan - I am a bit cautious to say that the SessionStore.load() method should be monkey patched. The concerning part is that the session store can be customized during deployment. Historically signed cookies have been used a lot, which do not suffer from this problem. In addition, I am not confident how many session stores have this issue or not. Finally, I think this issue is not new to Django, and they seem to have this behavior deliberately. It could be that changing this behavior could cause an even worse side effect (but honestly I do not know).

I think the patch thus far at least makes it so a simple curl script for the login page will not overwhelm the db. This is a good first step.

What Tihomir and I discussed via IRC was that we could probably make changes to the django-openstack-auth repo that would further improve things and reduce the likelihood of creating new sessions. Those changes are not complete at this point and will require some more work.

[Tristan Cacqueray (tristan-cacqueray)]

@Eric alright, sadly I suspect Paul's comment #13 to be still valid (considering the attack only need an extra crafted cookie).

In order to threat this as a Class A, we need a fix that really mitigate the attack for all supported release...

FYI, the other options are:
* fix this publicly (might help to get a patch in).
* threat this as a B2 class type of bug (which mean fix and/or security note).

How long do you think it will take to have such a fix covering django-openstack-auth ?

[Eric Peterson (ericpeterson-l)]

I have not found a way to make changes in the auth package that prevent session creation. As soon as a user is looked up (even an Anonymous user), a session record is created.

However, I have found an additional change in the horizon middleware can help. This change is needed in process_response, at the end of the method. This means it is one of the last things called. The code to add is:

        if not request.user.is_authenticated():
            request.session.delete(request.session.session_key)

For a db backed session, this calls:
https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L70

I am not sure how this works with the signed cookie base sessions, or even in the memcached sessions. Would this be an acceptable approach?

[Eric Peterson (ericpeterson-l)]

I just looked at signed cookies, cached, and cached db session backends. They all have a delete method with this signature. I *think* this should technically work.

[Tihomir Trifonov (ttrifonov)]

Thanks Eric for looking at the code. I promised to try to prepare the Django Auth patch, but couldn't manage to do it, sorry for that. Anyway - the proposed fix with process_response seems much more correct than the django-auth approach, as we might accidentally add some additional processing in another middleware, to check again for something in the session, and clearing the session at process_response seems to be the better way.

In Django, the persistence of SessionID in the Server(DB) is needed if we want to allow anonymous users to store some settings in session and not in cookie(e.g. when editing a comment under a blog - store drafts in the server session while the user is not yet logged in). Since Horizon doesn't allow anonymous users to any action, I think clearing the session is actually recommended. Each time anonymous user logs in the site - they will have unique session id, which is perfectly fine - they don't need anything else.

If someone can help with testing the proposed patch By Eric (https://bugs.launchpad.net/horizon/+bug/1394370/+attachment/4264463/+files/0001-Horizon-login-page-contains-DOS-attack-mechanism.patch) + the last 2 lines with process_response - should be great. I'd try to run few tests, but I'm on a very tight schedule this week.

[Tihomir Trifonov (ttrifonov)]

Here is the updated patch, containing the request.session.delete(request.session.session_key) code in process_response, but in a different middleware class.

Since we have this code in Django: https://github.com/django/django/blob/master/django/contrib/sessions/middleware.py#L49 the SessionMiddleware tries to save the session in case it is modified, and this is the case when logout is called for a logged in session. Since the user was logged in, then logged out, the session is marked as modified. The problem here is the order of execution of the middlewares - the SessionMiddleware is being executed after the HorizonMiddleware, so if we first try to clear/delete the session in HorizonMiddleware, then the SessionMiddleware processes the response, detects that is has been modified and tries to save it. This creates a new record in the DB with the sessionId of the logged-out user. So we need to process the response after the SessionMiddleware, so the proposed change is to add a CleanupMiddleware, that does the cleanup.

I've tested with signed_cookies and db - no visible drawbacks or problems. The tables seems clear after several logins, logouts, clean browser sessions.

A positive side-effect of the patch: no session cookie is being set in the response for anonymous users. In the current codebase - after an unsuccessful login, a cookie with the session_id is being returned to the users, thus exposing the SESSION_COOKIE_NAME to the user even if they don't have a valid account for the system. Now - until the user logs in for first time - no session cookie is being returned. When the users logs out - the Session cookie is being removed from response, so browser seems clear.

[Paul McMillan (paul-mcmillan)]

I'd like to see input from Gabriel Hurley on this patch, since this is one of his areas of expertise.

[Gabriel Hurley (gabriel-hurley)]

So here's my take:

1. A session is only saved if session.modified is true: https://github.com/django/django/blob/master/django/contrib/sessions/middleware.py#L18

2. django-openstack-auth is doing the same type of access in get_user as the default django database backend. Compare https://github.com/openstack/django_openstack_auth/blob/master/openstack_auth/utils.py#L51 and https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L147

3. I agree that the session clear and set_test_cookie are no longer needed; that's legacy code. I also agree that our call to _check_has_timed_timeout should be after checking if the user is authenticated.

What all this means is that simply *accessing* the session is not enough to write it to the DB; somewhere in these code paths we're triggering the session.modified flag. We should instead focus on finding where that's happening and ensure that we do not do anything to modify the session for anonymous sessions.

That would be a more appropriate fix for this as opposed to mucking with checking for a specific cookie name and/or deleting sessions if they're "unused".

[Paul McMillan (paul-mcmillan)]

I'm adding Donald who's a member of the Django security team, he may be able to help track down what we're doing wrong here.

[Donald Stufft (dstufft)]

I haven't read the entire ticket, however if this is your login view: https://github.com/openstack/horizon/blob/master/openstack_dashboard/views.py#L38-L48 then that's your problem right there. The request.session.clear() deletes the session and sets modified=True so it will create a new session.

I would recommend just flat out deleting that session manipulation code there. The Django login code already will ensure that session keys are rotated on authentication boundaries without creating a new session on every page load so the clearing of the session doesn't really do much of anything there. Setting the test cookie I don't think will hurt anything but I don't think you need it either TBH.

[Donald Stufft (dstufft)]

Note that accessing request.user does *not* create a session ever with Django. It will access the session yes, but it won't modify it and you require a modification to save a session (and thus create one if one doesn't already exist) unless you have SESSION_SAVE_EVERY_REQUEST set to True.

This is the clear code in Django -> https://github.com/django/django/blob/master/django/contrib/sessions/backends/base.py#L137-L143

It makes sense for the clear code to mark the session as modified because what's it's doing is emptying the session of all data, but it keeps the same session id.

Here's the login code in Django by the way as well -> https://github.com/django/django/blob/master/django/contrib/auth/__init__.py#L77-L105

It's acutally careful not to clear the session data when going from anonymous -> logged in, but to ensure that it does clear the session data when going from logged in (or thinks it's logged in) -> logged in with a different user.

[Eric Peterson (ericpeterson-l)]

A session record will get written to the DB if you:
- Just access (read from) request.session
- Just access request.user (which underneath, is also accessing request.session)

A good general intro is at http://stackoverflow.com/questions/4444758/huge-django-session-table-normal-behaviour-or-bug

The db session backend is forcing a session row to be created at:
https://github.com/django/django/blob/master/django/contrib/sessions/backends/db.py#L29
This essentially is saying if we couldn't find any session info, the db backend will generate a session ID for the user and write a row into the DB.

I agree that this in't a great behavior, but it is what I observe in a lot of trial and error tests.

@dstufft - yes, I would think accessing request.user wouldn't create a new session row, but that is not the case. When this code happens:
user_id = request.session[SESSION_KEY]
Then the session gets created in the db, even though that code will eventually bomb out with a key error for the SESSION_KEY.

I'd encourage others to set this stuff up and try it, how I would think things should work are not how things actually work ;) within django's session middleware.

[Eric Peterson (ericpeterson-l)]

I take back what I said above, I think I found another spot that was making session changes too.

I will have a simpler patch soon. Thanks all for your input (and patience :)).

[Donald Stufft (dstufft)]

Blugh. That should probably be changed in Django. There's no reason to create a session until one is being saved.

The session.clear() should still be dropped because even if the fixes land in Django then that will still cause a session to be created on each page load.

[Eric Peterson (ericpeterson-l)]

This patch is a simplified version of previous patches, and catches one more cookie modification we were making - which lead to extra session records.

I hope this is just about the last patch.

[Tihomir Trifonov (ttrifonov)]

The latest patch is still vulnerable, just make

    csrf=$(curl https://dashboard | grep csrfmiddlewaretoken-match-pattern)

Then run this request:

    curl -i https://dashboard/auth/login/ -d "csrfmiddlewaretoken=$csrf&region=http://dashboard:5000/v2.0&username=fake&password=fake" -b csrftoken=$csrf

You can repeat the request as many times as you want. Each run will add new row in DB.

But I think mystery is finally revealed:

First this:
https://github.com/openstack/django_openstack_auth/blob/455aaeab8d16fbecebe9a088e10e0e532a3116cb/openstack_auth/forms.py#L101

and then that:
Django 1.7:
https://github.com/django/django/blob/master/django/contrib/sessions/backends/base.py#L276

Django 1.6 (Ouch):
https://github.com/django/django/blob/stable/1.6.x/django/contrib/sessions/backends/base.py

So .flush() should be replaced with .delete(session_key), as in 1.6 it calls .create() and in 1.7 .clear() sets self.modified = True, but we don't have anything in session anyway.

My assumption is that Django wants to persist session, as by default websites might need to store user settings for anonymous users. Also, the sessionId is persisted for security reasons - since the session_key value is primary key in the Database, you cannot create duplicate sessionIds. Otherwise - if one user logs in and is assigned sessionId=123, then another user plays as anonymous, but for some reason the server assigns the same sessionId(possible in web farms) - they will be able to see the same as the logged-in user.

But Horizon doesn't actually need that. It doesn't offer anything to anonymous users. So Django should be probably able to handle the case with no anonymous sessions in DB as a general use case.

One minor drawback of the patch is that after a logout, a new session id is associated to the user, and it remains in the DB. But this should be generally OK for handling. To clear it - we still need the cleanup middleware.

The patch issues .delete() in django_openstack_auth, which works in 1.6 and 1.7 - no database rows added. And we can add the latest patch from Eric for horizon, as it makes things simple.

[Tihomir Trifonov (ttrifonov)]

Ouch - Django master is 1.8 alpha, so the both 1.6 and 1.7 issue .create() at the end of flush(). But all versions call clear() which sets .modified = True.

[Eric Peterson (ericpeterson-l)]

Awesome find Tihomir, I wonder if we just removed the flush altogether - if that would fix it perhaps? I am not sure why it is there in the first place.

[Tihomir Trifonov (ttrifonov)]

Eric is right, no need to flush/delete the session. Tested - no rows in DB without the .flush() line.

[Thierry Carrez (ttx)]

Impact desc on comment #14:
record resulting -> records, potentially resulting

Otherwise looks good to me

[Tristan Cacqueray (tristan-cacqueray)]

@Paul McMillan could you check if the proposed changes fix the issue ? ( openstack_auth in comment #38 and horizon in comment #34, assuming both are required.)

Here is the updated impact description draft #2 (thanks to Thierry review):

Title: Horizon denial of service attack through login page
Reporter: Eric Peterson (Time Warner Cable)
Products: Horizon
Versions: up to 2014.1.3 and 2014.2

Description:
Eric Peterson from Time Warner Cable reported a vulnerability in Horizon. By doing repeated requests to Horizon login page a remote attacker may generate unwanted session record, potentially resulting in a denial of service. All Horizon setups are affected.

[Eric Peterson (ericpeterson-l)]

(minor clarification)
I am not sure all Horizon setups are affected - I would say that Horizon setups using a db or memcached session engine would be impacted.

The default Horizon setting has been signed cookies in many cases, which does not suffer from this issue. (I am not sure which distros use signed cookies and which ones do not).

[Tristan Cacqueray (tristan-cacqueray)]

@Eric thanks for the clarification!

Here is the updated impact description draft #3 (including the session engine impact):

Title: Horizon denial of service attack through login page
Reporter: Eric Peterson (Time Warner Cable)
Products: Horizon
Versions: up to 2014.1.3 and 2014.2

Description:
Eric Peterson from Time Warner Cable reported a vulnerability in Horizon. By doing repeated requests to Horizon login page a remote attacker may generate unwanted session record, potentially resulting in a denial of service. Only Horizon setups using a db or memcached session engine are affected.

[Jeremy Stanley (fungi)]

The impact description looks great, aside from needing a handful of minor English grammar fixes in the second sentence:

By making repeated requests to the Horizon login page a remote attacker may generate unwanted session records, potentially resulting in a denial of service.

[Eric Peterson (ericpeterson-l)]

This patch reverts a change previously made to the middle ware tests, which was never needed.

[Lin Hua Cheng (lin-hua-cheng)]

Patch from comment #44 (horizon) and #38(django_openstack_auth) looks good to me.

[Paul McMillan (paul-mcmillan)]

Patches #38 and #44 also look good to me. The description as amended by Jeremy looks good to me.

[Tristan Cacqueray (tristan-cacqueray)]

CVE requested with this impact description:

Title: Horizon denial of service attack through login page
Reporter: Eric Peterson (Time Warner Cable)
Products: Horizon
Versions: up to 2014.1.3 and 2014.2

Description:
Eric Peterson from Time Warner Cable reported a vulnerability in Horizon. By making repeated requests to the Horizon login page a remote attacker may generate unwanted session records, potentially resulting in a denial of service. Only Horizon setups using a db or memcached session engine are affected.

[Tristan Cacqueray (tristan-cacqueray)]

@Eric the proposed fix conflict on stable/icehouse, can you please provide a backport ?

Also if we can send the advance notification by Thursday, we could do the disclosure at this date:
2014-12-09, 1500UTC

Is this working for everyone ?

[Lin Hua Cheng (lin-hua-cheng)]

@Tristan: Please find the icehouse version of the patch for horizon

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/140353

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/140354

[OpenStack Infra (hudson-openstack)]

Change abandoned by Lin Hua Cheng (<email address hidden>) on branch: stable/icehouse
Review: https://review.openstack.org/140354

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/140356

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/140358

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/140353
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=43ba4fe19a2d0c0e6b3d51f8eb7c5e9ca5afcf86
Submitter: Jenkins
Branch: master

commit 43ba4fe19a2d0c0e6b3d51f8eb7c5e9ca5afcf86
Author: eric <email address hidden>
Date: Thu Nov 20 08:49:09 2014 -0700

    Horizon login page contains DOS attack mechanism

    the horizon login page (really the middleware) accesses the session
    too early in the login process, which will create session records
    in the session backend. This is especially problematic when non-cookie
    backends are used.

    Change-Id: I9d2c40403fb9b0cfb512f2ff45397cbe0b050c71
    Closes-Bug: 1394370

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/140358
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=e8a66a4d92ae259a5ef004cafad1809942c66596
Submitter: Jenkins
Branch: stable/juno

commit e8a66a4d92ae259a5ef004cafad1809942c66596
Author: eric <email address hidden>
Date: Thu Nov 20 08:49:09 2014 -0700

    Horizon login page contains DOS attack mechanism

    the horizon login page (really the middleware) accesses the session
    too early in the login process, which will create session records
    in the session backend. This is especially problematic when non-cookie
    backends are used.

    Change-Id: I9d2c40403fb9b0cfb512f2ff45397cbe0b050c71
    Closes-Bug: 1394370

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/140356
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=61d09f6f96a22cd6c0ade58f6486cdbd118c5e2a
Submitter: Jenkins
Branch: stable/icehouse

commit 61d09f6f96a22cd6c0ade58f6486cdbd118c5e2a
Author: lin-hua-cheng <email address hidden>
Date: Mon Dec 1 18:16:15 2014 -0800

    Horizon login page contains DOS attack mechanism

    the horizon login page (really the middleware) accesses the session
    too early in the login process, which will create session records
    in the session backend. This is especially problematic when non-cookie
    backends are used.

    Change-Id: I9d2c40403fb9b0cfb512f2ff45397cbe0b050c71
    Closes-Bug: 1394370

[Julie Pichon (jpichon)]

For reference, django_openstack_auth review at https://review.openstack.org/#/c/140352/

[Matthias Runge (mrunge)]

as a follow-up here, sadly the fix introduced a regression, which I hope to fix with https://review.openstack.org/#/c/142737/