full-disclosure - Re: [Django] Cookie-based session storage session invalidation issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 3 Oct 2013 18:41:37 +0100
From: Paul McMillan <paul@...illan.ws>
To: "G. S. McNamara" <main@...cnamara.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Django] Cookie-based session storage session
 invalidation issue

Here's the commit that added the warning 2 years ago to the 1.4 documentation:
https://github.com/django/django/commit/6205a348f084cbab8d2953accecfc04b9fc75543

https://docs.djangoproject.com/en/1.4/topics/http/sessions/#using-cookie-based-sessions

Let me quote for you:

"No freshness guarantee

Note also that while the MAC can guarantee the authenticity of the
data (that it was generated by your site, and not someone else), and
the integrity of the data (that it is all there and correct), it
cannot guarantee freshness i.e. that you are being sent back the last
thing you sent to the client. This means that for some uses of session
data, the cookie backend might open you up to replay attacks. Cookies
will only be detected as ‘stale’ if they are older than your
SESSION_COOKIE_AGE."

While I agree that this might be unexpected behavior, I think it is
not unreasonable to expect developers to read the large warning
callout collocated with the feature they are enabling. Clearly it is
too much to ask of security researchers, however, so that section was
made even larger and more explicit.

-Paul

On Thu, Oct 3, 2013 at 3:39 PM, G. S. McNamara <main@...cnamara.com> wrote:
> Hi Paul,
>
> The documentation you linked to was updated yesterday to reflect the issue I
> brought up with cookie-stored sessions.
>
> Again, the behavior is a surprise to most developers.
>
>
> Thanks!
>
> G. S. McNamara
>
>
> On Wed, Oct 2, 2013 at 3:04 PM, Paul McMillan <paul@...illan.ws> wrote:
>>
>> G. S. McNamara:
>>
>> Perhaps next you will disclose that if an attacker obtains a user's
>> password, they can log in as that user. Seriously, "full disclosure"
>> of well documented behavior is not particularly impressive.
>>
>>
>> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
>>
>> Cheers,
>> -Paul
>>
>> > From: "G. S. McNamara" <main@...cnamara.com>
>> > To: <full-disclosure@...ts.grok.org.uk>
>> > Subject: [Full-disclosure] [Django] Cookie-based session storage session
>> > invalidation issue
>> >
>> > FD,
>> >
>> > I’m back!
>> >
>> > Django versions 1.4 – 1.7 offer a cookie-based session storage option
>> > (not the default > this time) that is afflicted by the same issue I posted
>> > about previously concerning Ruby > on Rails:
>> >
>> > If you obtain a user’s cookie, even if they log out, you can still log
>> > in as them.
>> >
>> > The short write-up is here, if needed:
>> > http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
>> >
>> > Cheers,
>>
>> _______________________________________________
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/