News for hackers. Stuff that matters.
Re:Security advisory: Breach and Django by jacobian on Tuesday August 06, 2013 @10:51AM (#6166872)
Again, we believe that sessions and CSRF protection can be orthangonal (and that there are benefits to doing so). If you can prove otherwise, let us know!

There's also https://github.com/mozilla/django-session-csrf, an alternate CSRF implementation by Mozilla that does use session-linked CSRF tokens. So if you insist on "tokens must be session-linked", you can use that instead.

Re:Security advisory: Breach and Django by homakov on Tuesday August 06, 2013 @10:56AM (#6166887)
sorry, I think in terms of Rails, in rails a session is a _site_sess cookie... i am not sure how it works in Django but what here is a post about it http://homakov.blogspot.com/2013/06/cookie-forcing-protectio...

https://github.com/mozilla/django-session-csrf seems ok, should be default

Re:Security advisory: Breach and Django by JshWright on Tuesday August 06, 2013 @11:03AM (#6166944)
"i am not sure how it works in Django"

Perhaps you should do a little research before proclaiming things insecure?

Re:Security advisory: Breach and Django by homakov on Tuesday August 06, 2013 @11:27AM (#6167087)
bitbucket is vulnerable > django has a problem

if it's not enough:

some websites from http://www.djangosites.org/ are vulnerable > django has a problem

Re:Security advisory: Breach and Django by homakov on Tuesday August 06, 2013 @11:03AM (#6166943)
and yes, they clearly state it was made as a solution to cookie forcing:

>Your site is on a subdomain with other sites that are not under your control, so cookies could come from anywhere.

it should be default, for sure.