Opened 7 years ago

Closed 7 years ago

Last modified 4 years ago

#7515 closed (fixed)

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

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

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

Download all attachments as: .zip

Change History (18)

Changed 7 years ago by mrts

comment:1 Changed 7 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to jacob
  • Patch needs improvement unset
  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 7 years ago by telenieko

  • Needs documentation set

new method, new docs ;)

comment:3 Changed 7 years ago by mrts

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.

Changed 7 years ago by anonymous

comment:4 Changed 7 years ago by telenieko

  • Needs documentation unset

Changed 7 years ago by mrts

Rephrased docs as per suggestions on the IRC.

comment:5 Changed 7 years ago by Simon Greenhill

  • Triage Stage changed from Accepted to Ready for checkin

comment:6 Changed 7 years ago by mrts

  • Triage Stage changed from Ready for checkin to Design 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.

Changed 7 years ago by mrts

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

comment:7 Changed 7 years ago by mrts

  • Summary changed from Add .clear() to session objects to Add .clear() and .destroy() to session objects

Changed 7 years ago by mrts

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

comment:8 Changed 7 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

comment:9 Changed 7 years ago by jacob

  • Owner changed from jacob to mtredinnick
  • Status changed from assigned to new

comment:10 Changed 7 years ago by mtredinnick

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

comment:11 Changed 7 years ago by mtredinnick

(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 Changed 7 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

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 Changed 4 years ago by jacob

  • milestone 1.0 beta deleted

Milestone 1.0 beta deleted

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