#14634: Sessions are unnecessarily complex
----------------------------------------------+-----------------------------
Reporter: PaulM | Owner: PaulM
Status: new | Milestone: 1.3
Component: django.contrib.sessions | Version: 1.2
Resolution: | Keywords:
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
----------------------------------------------+-----------------------------
Comment (by lukeplant):
Personally I'm in favour of fixing #14579 to enable a cookie backend.
There is also a pretty good argument for retaining this check even when
storing the data in a 'trusted' datastore - essentially that not all
pieces of infrastructure are equally trusted or equally open to attack,
and layers of security are good.
Consider a situation where the attacker has write access to the database,
but not read or write access to the source code of the application. In
many situations, that will be 'game over' as far as security is concerned,
but not all. Alternatively, consider the case where the attacker has write
access to part of the filesystem, or the cache backend, but nothing else,
and the app is using the filesystem or cache session backend. Now, it is
relatively easy to create 'pickled' values that will execute arbitrary
commands when unpickled (not just provide arbitrary values). So, without
this tamper check, a breach of filesystem/cache/database will escalate
into the ability to execute arbitrary commands.
A real life situation where this might occur is a shared hosting
environment where the '/tmp' directory is used for the filesystem session
backend — which is the default directory for the filesystem session
backend. Since this directory is often world-writable (even if the files
created there are not world readable), an attacker could well use this to
do arbitrary code injection. A quick check on a server I know suggests
this might well be a very practical attack since I can see hundreds of
files in /tmp that appear to be PHP session files. Although I can't read
them, I think I can delete them easily, and if they were Django session
files with no tamper check then I could replace them with some malicious
data. The owners of the corresponding web apps certainly have some
security issues - I can delete all of their sessions - but with a tamper
check in place, it is no worse than that.
So, I'm pretty strongly in favour of keeping this layer of protection. It
is a worthwhile check given the escalation of privileges it could prevent
in some fairly likely situations.
--
Ticket URL: <http://code.djangoproject.com/ticket/14634#comment:2>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-upda...@googlegroups.com.
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
