6 ms·

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,

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).

homakov 13y ago
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/ 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)
- jacobian 13y ago
  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 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?
  - homakov 13y ago
    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/ http://www.djangosites.org/ are vulnerable.
- antihero 13y ago
  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?
  - homakov 13y ago
    XSS? unrelated here I think. Exactly, cookie forcing/tossing = "set" their CSRF token
antihero 13y ago
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?
- donaldstufft 13y ago
  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.
  - antihero 13y ago
    Except we can set the cookie because we're already doing that to HTTPS requests via cookie-forcing.
    - donaldstufft 13y ago
      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.
      - homakov 13y ago
        > 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 13y ago

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

jacobian 13y ago
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 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?
- homakov 13y ago
  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/ http://www.djangosites.org/ are vulnerable.
antihero 13y ago
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?
- homakov 13y ago
  XSS? unrelated here I think. Exactly, cookie forcing/tossing = "set" their CSRF token

antihero 13y ago

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?

donaldstufft 13y ago
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.
- antihero 13y ago
  Except we can set the cookie because we're already doing that to HTTPS requests via cookie-forcing.
  - donaldstufft 13y ago
    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.
    - homakov 13y ago
      > 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.