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

["G. S. McNamara" <main () gsmcnamara com>]

Now that we're in agreement about the vulnerability and are getting off
topic, I think this thread has run its course. If you have an issue with me
let's spare the FD subscribers and you can contact me directly.


Thanks!

G. S. McNamara


On Thu, Oct 3, 2013 at 4:12 PM, Paul McMillan <paul () mcmillan ws> wrote:

> The technical properties of the feature (entirely client-side
> sessions) require this behavior. As you rightly pointed out, this
> brings with it some limitations, including the inability to
> prematurely expire a session. This, and other properties of this
> session backend are why it is not the default backend, and why there
> are explicit warnings about it. Nevertheless, it is useful in some
> deployment scenarios. I agree that the current even more explicit
> warning is better.
>
> You might want to include a recommendation for shorter session
> timeouts in your blog post, since that works relatively well to combat
> this problem in deployments which require client-side sessions.
>
> On Thu, Oct 3, 2013 at 8:34 PM, G. S. McNamara <main () gsmcnamara com>
> wrote:
> > Not sure why all the hostility.
>
> You write a blog post, and post to FD, waving around a "newly
> discovered vulnerability" that was a carefully and deliberately chosen
> design decision made during the implementation of the feature.
> Furthermore, you didn't have the decency to email the project security
> alias to inquire about this until the day after posting about it
> publicly. This is FD, so I'm not going to comment further on that
> behavior, but perhaps you can imagine why your praises are not being
> sung particularly loudly.
>
> -Paul
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/