Opened 16 years ago

Closed 16 years ago

Last modified 13 years ago

#7515 closed (fixed)

Add .clear() and .destroy() to session objects

Reported by: mrts Owned by: Malcolm Tredinnick
Component: contrib.sessions Version: dev
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Reliable session clearing is required to avoid fragile (another thread may delete a key and cause an exception in the loop given in the snippet) and cumbersome tricks like http://www.djangosnippets.org/snippets/681/ .

See also http://groups.google.com/group/django-developers/browse_thread/thread/fbcfa88c997d1bb3 .

Note that this doesn't reset the session key, only the data associated with the key. Other frameworks tend to reset the key as well. I believe this is redundant, but feel free to correct me. The reasoning behind that claim is as follows:

session key -> sensitive data
clear session, but don't reset the key
session key -> no data
=> therefore no sensitive information leaked, as the key per se is public, only the data set behind it is private

Attachments (5)

session_clear.diff (1014 bytes ) - added by mrts 16 years ago.
session_clear-with_docs.diff (1.5 KB ) - added by anonymous 16 years ago.
session_clear-with_docs2.diff (1.5 KB ) - added by mrts 16 years ago.
Rephrased docs as per suggestions on the IRC.
clear_and_destroy.diff (8.5 KB ) - added by mrts 16 years ago.
Exception-safe destroy() added to request.session, with tests and docs
clear_and_destroy2.diff (8.4 KB ) - added by mrts 16 years ago.
Remove redundant .save()s from tests and update to r8158

Download all attachments as: .zip

Change History (18)

by mrts, 16 years ago

Attachment: session_clear.diff added

comment:1 by Jacob, 16 years ago

Owner: changed from nobody to Jacob
Status: newassigned
Triage Stage: UnreviewedAccepted

comment:2 by Marc Fargas, 16 years ago

Needs documentation: set

new method, new docs ;)

comment:3 by mrts, 16 years ago

The "proof" behind the claim should read as follows (where -> designates mapping and '=>' implication):

session key X -> sensitive data for user A
clear session, but don't reset the key
session key X -> no data
reuse session key for user B
session key X -> sensitive data for user B
=> therefore no sensitive information leaked, as the key per se is public, only the data set behind it is private

Attaching docs as per Jacob's request.

by anonymous, 16 years ago

comment:4 by Marc Fargas, 16 years ago

Needs documentation: unset

by mrts, 16 years ago

Rephrased docs as per suggestions on the IRC.

comment:5 by Simon Greenhill, 16 years ago

Triage Stage: AcceptedReady for checkin

comment:6 by mrts, 16 years ago

Triage Stage: Ready for checkinDesign decision needed

One could argue that not resetting the session key is not exception safe:

  • session key X -> sensitive data for user A
  • clear session, but don't reset the key
  • session changed, empty session needs to be cleared from db
  • db connection has died, exception, session.save() fails
  • old key remains in browser, will be reused for user B
  • db comes online again
  • user B visits site and gets access to user A's sensitive data as the cookie and session key have not changed

So, I'd propose leaving clear() as is and adding reset() or destroy() that

  • generates a new key
  • calls clear() in try/catch
  • assigns the new key to the new session in finally and re-raises the exception that was thrown
  • assures that the old cookie is removed from browser and perhaps a new one sent regardless of exceptions thrown

Obviously, if B has maliciously stolen A's session this doesn't help. It's only good for the common inadvertent case.

by mrts, 16 years ago

Attachment: clear_and_destroy.diff added

Exception-safe destroy() added to request.session, with tests and docs

comment:7 by mrts, 16 years ago

Summary: Add .clear() to session objectsAdd .clear() and .destroy() to session objects

by mrts, 16 years ago

Attachment: clear_and_destroy2.diff added

Remove redundant .save()s from tests and update to r8158

comment:8 by Jacob, 16 years ago

Triage Stage: Design decision neededAccepted

comment:9 by Jacob, 16 years ago

Owner: changed from Jacob to Malcolm Tredinnick
Status: assignednew

comment:10 by Malcolm Tredinnick, 16 years ago

(In [8341]) Added a clear() method to sessions. Patch from mrts. Refs #7515.

comment:11 by Malcolm Tredinnick, 16 years ago

(In [8342]) Implemented a flush() method on sessions that cleans out the session and
regenerates the key. Used to ensure the caller gets a fresh session at logout,
for example.

Based on a patch from mrts. Refs #7515.

comment:12 by Malcolm Tredinnick, 16 years ago

Resolution: fixed
Status: newclosed

I'm not going to worry about the attempt at exception-proofing mentioned in comment 6. That only trades one race condition for some other ones. The random numbers could collide. The network between the server and the browser could fail to deliver the message. The user could turn off their browser or computer before the reply gets back, etc. There's no way to completely guarantee that the updated cookie will reach their browser, so there's always a low-probability chance of failure.

comment:13 by Jacob, 13 years ago

milestone: 1.0 beta

Milestone 1.0 beta deleted

Note: See TracTickets for help on using tickets.
Back to Top