Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 4 Oct 2013 01:26:46 -0400
From: Donald Stufft <donald@...fft.io>
To: oss-security@...ts.openwall.com,
 kseifried@...hat.com
Subject: Re: A note on cookie based sessions

I don't think this really is a vulnerability is it? I mean it's basically how
the internet works. The only difference between a cooke backed session
and a regular session is that there's no server side session to destroy.
At least in Django's case, It's not a permanent session though, they are
only good for a limited amount of time before the signature on the cookie
expires.

If you have access to the session cookie you've already won the game, you've
gotten an XSS or MITM and can do much worse then a session cookie.

On Oct 4, 2013, at 12:40 AM, Kurt Seifried <kseifried@...hat.com> wrote:

> Signed PGP part
> So this has been published:
> 
> http://maverickblogging.com/logout-is-broken-by-default-ruby-on-rails-web-applications/
> 
> http://maverickblogging.com/security-vulnerability-with-django-cookie-based-sessions/
> 
> Basically it boils down to this: cookie based session handling where
> you don't store state data on the backend, but instead have a cookie,
> possibly with an expiration time coded into it can be used in replay
> attacks.
> 
> That's a problem, but also an inherent limitation of how such session
> handling works. The advantages are a stateless backend, no need for
> state DB, if you have many backends, especially distributed, logins
> just work no matter which server you connect to.
> 
> In both Drupal and Ruby on Rails case the security issues are documented:
> 
> https://docs.djangoproject.com/en/1.5/topics/http/sessions/#using-cookie-based-sessions
> 
> http://guides.rubyonrails.org/action_controller_overview.html#session
> 
> the documentation can maybe be improved (especially mentioning
> HTTPS/HSTS to prevent sniffing of the cookie) but generally speaking
> this is covered, so no CVEs here.
> 
> - -- 
> Kurt Seifried Red Hat Security Response Team (SRT)
> PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> 


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA


Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.