What are the risks of not cycling session keys in Django?

user_34935 0
Viewed 80

Django cycles the session key upon login. The rationale (that I don't understand) is in this pull request:

When logging in, change the session key whilst preserving any existing sesssion. This means the user will see their session preserved across a login boundary, but somebody snooping the anonymous session key won't be able to view the authenticated session data.

Cycling the session key is awkward if you wish to easily associate unauth behavior with a later logged-in user. This answer suggests simply disabling cycle_key.

What risks are there in disabling cycle_key? (Related to the comment above, or others.)

EDIT: Okay, I think I understand the rationale above. It literally means that if you snooped unauth actions, you won't be able to associate them with auth actions. I can see how that might be nice, but 1) ideally both unauth and auth actions are protected (e.g., https), 2) that security benefit has to be weighed with the benefit of preserving the session key.

EDIT 2: The pull request is from 2008, when the https landscape was way different. Now it's >=90% https.

django-sessions security django
1 Answers

Looking at the documentation for cycle_key it says (emphasis mine):

Creates a new session key while retaining the current session data. django.contrib.auth.login() calls this method to mitigate against session fixation.

Hence, the reason the session key is cycled is to prevent a session fixation attack [OWASP]. After some research a session fixation attack is basically where the attacker obtains a session id (or uses an arbitrary one) from the server and through some means (XSS attacks, MITM attacks, etc.) forces some other user to use this session id to authenticate to your server. In case the session key is not changed by the server here the attacker can now take over the users session and impersonate them.

Hence disabling this is a big risk and the returns for disabling this are also quite small. I would advice you (and anyone reading this) not to disable this builtin feature, in fact don't disable any of Django's security features without thinking well about it.

About associating unauthenticated behavior with authenticated behaviour that is better done by storing the data by serializing it in the users session itself as described in the second method of this answer by Gonzalo.

user_149918640
Related