Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#7515 closed (fixed)

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

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

Download all attachments as: .zip

Change History (18)

Changed 8 years ago by mrts

Attachment: session_clear.diff added

comment:1 Changed 8 years ago by Jacob

Needs documentation: unset
Needs tests: unset
Owner: changed from nobody to Jacob
Patch needs improvement: unset
Status: newassigned
Triage Stage: UnreviewedAccepted

comment:2 Changed 8 years ago by Marc Fargas

Needs documentation: set

new method, new docs ;)

comment:3 Changed 8 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 8 years ago by anonymous

comment:4 Changed 8 years ago by Marc Fargas

Needs documentation: unset

Changed 8 years ago by mrts

Rephrased docs as per suggestions on the IRC.

comment:5 Changed 8 years ago by Simon Greenhill

Triage Stage: AcceptedReady for checkin

comment:6 Changed 8 years ago by mrts

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.

Changed 8 years ago by mrts

Attachment: clear_and_destroy.diff added

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

comment:7 Changed 8 years ago by mrts

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

Changed 8 years ago by mrts

Attachment: clear_and_destroy2.diff added

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

comment:8 Changed 8 years ago by Jacob

Triage Stage: Design decision neededAccepted

comment:9 Changed 8 years ago by Jacob

Owner: changed from Jacob to Malcolm Tredinnick
Status: assignednew

comment:10 Changed 8 years ago by Malcolm Tredinnick

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

comment:11 Changed 8 years ago by Malcolm Tredinnick

(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 8 years ago by Malcolm Tredinnick

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 Changed 5 years ago by Jacob

milestone: 1.0 beta

Milestone 1.0 beta deleted

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