User Session leakage
Adam Seering
I've been working on a reasonably large internal site using Django.
I was hitting the problem that user logins seemed to be getting
confused; ie., two users logged in at the same time would
occasionally switch 'User' database entries in request.user; one
user's request.user would point to the other's account. This site
tends to have 15-20 people on it at a time at peak usage, and page
generation takes long enough that two users actually having active
connections at once is quite probable.
I assumed this was a bug in my code; it wouldn't be the first...,
and this is a large project with too few test cases and such.
However, I recently wrote another small program in Django, completely
from scratch (ie. no shared codebase). This separate program also
exhibited the "shared user account" problem. This other program was
a small AJAX+Django chat widget, used over the course of a weekend by
~150 people; there were definitely concurrent sessions.
This is getting really annoying. Anyone have any ideas on how to
debug it?
Thanks,
Adam
Jeremy Dunck
What's your server setup (modpy, flup, ...?)
Are you using a proxy?
What client browsers are being used?
Assuming the server is sane, the session cookie is the only thing
determining the request.user, so I suspect either your server isn't
sane (as in, threading is killing you), or something is wrong with
downstream caches.
James Bennett
> Assuming the server is sane, the session cookie is the only thing
> determining the request.user, so I suspect either your server isn't
> sane (as in, threading is killing you), or something is wrong with
> downstream caches.
Or he's using a version of Django prior to revision 3754, which fixed
a subtle bug in the way request.user is set up. Applying this diff
should clear up the problem:
http://code.djangoproject.com/changeset/3754
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Jeremy Dunck
...
> Or he's using a version of Django prior to revision 3754, which fixed
> a subtle bug in the way request.user is set up. Applying this diff
> should clear up the problem:
Ah, for clarity, that existed on trunk from [2809] (magic-removal) to [3764].
In Django prior to magic-removal, the auth middleware wasn't separate,
and the request handler itself set up the request.user attribute.
*whew*
Adam Seering
Applying that patch does seem to have helped on the first server;
it's a probabilistic problem, but at least we haven't seen it since
trying this.
The first server was running Debian Etch; the second was running
Gentoo. Both were using Django as installed from their local repo's
(based on 0.95), not directly from SVN. Out of curiosity, is there a
way to determine the version of Django that a package uses, if it
doesn't contain .svn files?
Thanks,
Adam
Jeremy Dunck
> way to determine the version of Django that a package uses, if it
> doesn't contain .svn files?
django.VERSION gives a rough idea, though it's not updated between
"official" releases.
If you don't have django.VERSION, you're using a version prior to
0.95, I believe.
Adam Seering
In [1]: from django import VERSION
In [2]: VERSION
Out[2]: (0, 95, None)
Out of curiosity, is there a log somewhere of major security holes
that are fixed since a release? And, how does one get security
patches into the releases used in major distro's?; who dropped the
ball on this one?
We're not eager to use the SVN HEAD version of source on our main
servers. The Django API-change docs are good, but not that good; we
have had code break unexpectedly in the past after "svn up"'s, and
that just makes us sad when it happens. On the other hand, we really
don't want security issues to bite us; we're imposing in code
security restrictions that exist for legal reasons, and we _really_
can't afford that kind of problem in our underlying Web framework.
Some of the people on this project are having serious concerns about
the choice to use Django for this particular project; do folks have
any thoughts/answers for them?
Thanks,
Adam
James Bennett
> Out of curiosity, is there a log somewhere of major security holes
> that are fixed since a release? And, how does one get security
> patches into the releases used in major distro's?; who dropped the
> ball on this one?
Per the docs on security issues[1], there will either be an entirely
new release, if warranted, or a patch released which can be applied to
fix any security vulnerability. The policy is to release patches for
the current released version and the two previous releases; at the
moment, that means 0.95, 0.91 and 0.90 (there are "bugfixes" branches
in the repository for 0.90 and 0.91 for this purpose, which exist only
to collect security fixes and patches for known bugs in those
releases). There's also a low-traffic announcements-only mailing list
-- django-announce[2] -- used to send out notifications when this sort
of thing happens (though in the past such announcements have also
usually been cross-posted to the django-users and django-developers
lists, just for good measure).
I believe that at the time this bug was found and fixed, our
security-reporting and notification infrastructure wasn't yet in
place, which is why there isn't an announcement out for it.
> We're not eager to use the SVN HEAD version of source on our main
> servers.
The patch for this should apply cleanly to 0.95; I don't personally
know whether it'll be retroactively applied into the 0.95 release
distribution or not, though. I think we do need to find some way to
draw attention to this patch, however, because it's an important
post-0.95 fix.
> Some of the people on this project are having serious concerns about
> the choice to use Django for this particular project; do folks have
> any thoughts/answers for them?
I'm not sure really what sort of answers there are to give; there
aren't any silver bullets which magically make web development "safe".
The best you can do is carefully evaluate a product before you start
using it, and continue evaluating it as you go; I've written up some
thoughts on that with respect to web frameworks[3], but again, there
are no universal answers to security questions; anyone who tries to
tell you otherwise is selling something.
[1] http://www.djangoproject.com/documentation/contributing/#reporting-security-issues
[2] http://groups.google.com/group/django-announce/
[3] http://www.b-list.org/weblog/2006/08/13/lets-talk-about-frameworks-security-edition
Jeremy Dunck
> We're not eager to use the SVN HEAD version of source on our main
> servers. The Django API-change docs are good, but not that good; we
> have had code break unexpectedly in the past after "svn up"'s, and
> that just makes us sad when it happens.
While I understand that reasoning, you may want to take something
closer to trunk for now, and regularly have an update/test cycle in
dev. 0.95 was 6 months ago, nearly 900 revs.
Perhaps we should have an 0.95 bugfix branch, and backport this issue to it.
Adam Seering
On Jan 17, 2007, at 10:01 PM, James Bennett wrote:
>> Some of the people on this project are having serious concerns about
>> the choice to use Django for this particular project; do folks have
>> any thoughts/answers for them?
>
> I'm not sure really what sort of answers there are to give; there
> aren't any silver bullets which magically make web development "safe".
I agree, certainly. I understand that this sort of bug will,
unfortunately, come up occasionally. Our concern is that it's been
order of a thousand SVN revisions since its patch was submitted, and
a version of the code with this bug is still being distributed as a
major release, with no warning to new users that the code is unsafe.
I've been using Django since before this security policy was posted,
so I hadn't seen it; I always assumed that Django would have one
additional item on the list: - Apply the patch to the downloadable
distribution, at all locations where it's available, so naive new
users don't get bitten by old bugs.
The question really was, Is Django's policy to do this? If so, what
went wrong, and are there mechanisms in place to keep it from
happening again? If not, we're not sure what we will do; in terms of
evaluating frameworks as we go, Django has just dropped a rather
large notch in our view of things.
Thanks,
Adam
Adam Seering
This does seem to be the common practice in such frameworks; this is,
after all, the purpose of a release: It's a fairly stable codebase
that will be maintained for an extended period of time, with bug
fixes / security patches / etc. Otherwise, you could just tell
people to check out a particular SVN version, or have nightly
tarballs or something.
If you don't do that, I really think that Django should add a section
to its download page: "This release version has a list of known
security bugs. <possibly insert list here> Please download patches
for them." This, of course, is highly awkward. Then again, isn't
distributing "release" code with known and fixed security holes, also
awkward?
Thanks,
Adam
d...@simon.net.nz
(partly caused by this thread I think) in Django Developers here:
http://groups.google.com/group/django-developers/browse_thread/thread/14071de102b62ed7
& James Bennett has been appointed Release Manager:
http://groups.google.com/group/django-developers/browse_thread/thread/9cc70167a6af4a03
including releasing 0.95.1 which will include these security fixes, and
this policy should clear all this up in future.
--Simon G.
James Bennett
> including releasing 0.95.1 which will include these security fixes, and
> this policy should clear all this up in future.
Yup, the fix is already committed to a new "0.95-bugfixes" branch, and
that branch will, in the next day or so, become the 0.95.1 release.