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]

Message-ID: <CAAsS5moX900mahqgM-x4=ncOjmSehzicWZFJMpX0k_vA66o20w@mail.gmail.com>
Date: Thu, 3 Oct 2013 15:34:10 -0400
From: "G. S. McNamara" <main@...cnamara.com>
To: Paul McMillan <paul@...illan.ws>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Django] Cookie-based session storage session
 invalidation issue

Perhaps I need to better clarify the subtle difference I am pointing out:

When "replay attacks" is mentioned in the documentation and elsewhere it
tends to give examples of actions that can be taken (again) within an
existing session on behalf of a user, such as re-purchasing a product from
a shopping website. It does not talk about how the session itself can
be exhumed, which developers consider a BFD and should really be
highlighted explicitly.

The additional detail is appreciated now that the official stance is that
this risk is going to be accepted.

Not sure why all the hostility.


Thanks!

G. S. McNamara


On Thu, Oct 3, 2013 at 1:41 PM, Paul McMillan <paul@...illan.ws> wrote:

> 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/
> >
> >
>

Content of type "text/html" skipped

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