Hacker News Reader

Comment by jacobian | Hacker News Reader

To your second point, security@djangoproject.com. It's documented in a bunch of places; where'd you look for it? I'll add it there, too :)

To the first point, we believe that Django's CSRF protection is as strong as session-linked CSRF protection, and adds CSRF protection to anonymous users (users without a session as well). In other words, it's a design decision, one that we believe doesn't compromise CSRF protection. If you believe otherwise, please get in touch (see above).

View on HN

1) session and logged in/out user are two different things. Session is the way you store information about current user, no matter he is anonymouse or logged in.

2) I checked again for instance https://bitbucket.org/ - edit csrftoken cookie to any, 123123 for example. Reload the page and if site keeps working - Cookie Forcing with MITM will do the same thing using http: injector Set-Cookie

not only MITM, subdomains can do precisely same thing. Either bitbucked uses old django or django is vulnerable to it (which is, well, a severe vulnerability imo)

1) I know the difference between sessions and logging in. I didn't say anything about logging in; I said that our CSRF protection protects users without sessions. Not all sites use sessions (some for performance reasons, others for privacy reasons); must those sites be vulnerable to CSRF?

2) First, you should report this to Bitbucket: https://www.atlassian.com/security. And c'mon, disclosing a possible CSRF vulnerability on a public board is kinda irresponsible. Is responsible disclosure not something you practice?

SecondI don't know what Bitbucket is running, exactly, and exrapolating from Bitbucket to Django is pretty lazy. Frameworks != sites. Once again, we've spent quite of bit of time validating the design and implementation of Django's CSRF protection, and we believe it works. If you find proof otherwise, can you please send it to security@djangoproject.com, and not post it to Hacker News?

1) only to make sure we are on the same page. Now I see - we have different understanding of "session".

>Not all sites use sessions (some for performance reasons, others for privacy reasons);

what kind of site doesn't use sessions? To track a user you need a cookie right?

2) Frameworks != sites. As I used to think, only framework is responsible for CSRF protection, hence I extrapolated. I sent it to security@ as soon as I found this email. I am trying to not proclaim anything but some websites from http://www.djangosites.org/ are vulnerable.

Could you clarify what actually can be done by this? From what I can see, you can't do XSS because it's escaped.

I guess there's the chance that you could do CSRF because you've essentially "set" their CSRF token?

XSS? unrelated here I think.

Exactly, cookie forcing/tossing = "set" their CSRF token

Ok, plausible attack I thought up based on what I could suck up from homakov's and various other posts:

1. User is browsing an HTTPS Django site and a HTTP site on WiFi.

2. Hacker is MITMing a connection (on WiFi), cannot decrypt SSL.

3. Changes user's CSRF token for Django via cookie-forcing.

4. Hacker can now use user's other HTTP session, and inject JS (or whatever) so their browser sends stuff to the HTTPS Django site, fully knowing their CSRF token (because we set it) and thus can forge requests easily.

Does Django mitigate something like that already? I think should be pretty easy to mitigate by using Django's signing to sign the session ID or something into the CSRF token?

An unrelated HTTP session cannot set a cookie for another domain (unless it's a subdomain in which you have the more serious issue of session theft or session fixation). The solution to both of these problems is HSTS with the includeSubDomains option.

Except we can set the cookie because we're already doing that to HTTPS requests via cookie-forcing.

I've just woken up and I haven't tested it, but off the cuff I believe HSTS will prevent the browser from trusting a plaintext HTTP response at all. So you cannot force a cookie if I understand the blog post correctly. You'd have to create a cookie inside of a verifiable HTTPS connection, which if you can do you've already executed a much worse attack.

> but off the cuff I believe HSTS will prevent the browser from trusting a plaintext HTTP response at all

Cookies are broken (i write about it on my blog like, daily). The essential idea of Forcing is injecting cookies into HTTPS space from HTTP.

@homakov, so you can get a browser to trust a cookie from a HTTP response under a domain protected by HSTS?

Doesn't HSTS just mean that the browser will just always make HTTPS responses?

I think this is what it hinges on:

http://scarybeastsecurity.blogspot.com.es/2008/11/cookie-for...

Is that possible under HSTS?

1) simulate request to http(NOT SECURE)://site.com 2) simulate response with Set-Cookie: csrf_token=123123;

> unless it's a subdomain in which you have the more serious issue of session theft or session fixation

elaborate plz? From what I know, subdomain can only do same attack (cookie tossing). Are you talking about phishing?

Reply on news.ycombinator.com