SessionId collision - session takeover by accident
|Reported by:||Owned by:||Adrian Holovaty|
|Severity:||Keywords:||sessionid session patch|
|Cc:||Triage Stage:||Ready for checkin|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||yes|
I just had an accidental session takeover at a clients web site.
My session settings:
SESSION_COOKIE_SECURE = True SESSION_EXPIRE_AT_BROWSER_CLOSE = True SESSION_COOKIE_AGE = 70000
Python 2.5, Django SVN Revision: 5320, OpenBSD 4.1, lighttpd with FastCGI
After checking the generation of the sessionid I found that there may be
the following reasons (in combination):
- very low traffic site (at the moment)
- I had a very short session before logging in again, I used the logout link (admin interface).
- no deletion of the session cookie when logging out (not sure about that but it would explain the behaviour)
- five django processes, each having its own seeded random module
- exclusive use of fixed data or determined data for the sessionid generation
I think I reused my old sessionid by still having the cookie. Between logging
out and logging in again another user got the same sessionid (because it
was not in the database anymore). So I got an authenticated session from the
A patch is provided, maybe even the remote IP should be included in feeding md5.
The session cookie should also be deleted when using a logout link.
Change History (8)
comment:1 Changed 10 years ago by
|Summary:||SessionId collision - session takeover by accident → [patch] SessionId collision - session takeover by accident|
comment:2 follow-up: 3 Changed 10 years ago by
|Patch needs improvement:||set|
|Summary:||[patch] SessionId collision - session takeover by accident → SessionId collision - session takeover by accident|
|Triage Stage:||Unreviewed → Accepted|