5 ms·

im a rabbit

by homakov 13y ago

im a rabbit

homakov 13y ago
Rails is not vulnerable to cookie forcing btw. But your authentication can be (Devise bug http://blog.plataformatec.com.br/2013/08/csrf-token-fixation-attacks-in-devise/ http://blog.plataformatec.com.br/2013/08/csrf-token-fixation... )
JshWright 13y ago
>And i was trying to report it, but didn't find a contact/email. How hard did you try? Django uses the industry standard security@ address for reporting security issues. A quick googling results in this page pretty easily: https://docs.djangoproject.com/en/1.5/internals/security/ https://docs.djangoproject.com/en/1.5/internals/security/ EDIT: I described the link as 'first' in the Google results, but that was because Google was being helpful and promoting a page I've visited a lot before... In reality, it's a few links down.
- homakov 13y ago
  1) open https://www.djangoproject.com/ https://www.djangoproject.com/ 2) find /contact/, /email/, user group
  - steveklabnik 13y ago
    I've never really looked at Django's site before, picked 'community' on the upper right, and it says > Report potential security issues in Django via private email to > security@djangoproject.com, and not via Django's Trac instance or the > django-developers mailing list
  - JshWright 13y ago
    The community page (where all the mailing lists and contact addresses are listed) say: >Report potential security issues in Django via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers mailing list
homakov 13y ago
P.S. i am not into django, but if you have a clue how to contact authors... please tell them to put CSRF token into session cookie. It must be fixed in the first place, BREACH is 100 times harder and longer, while cookie forcing is completely viable attack with active MITM. Or perhaps it was fixed? I checked it on bitbucket the last time..
- jacobian 13y ago
  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 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.
  - homakov 13y ago
    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-protection-made-easy.html http://homakov.blogspot.com/2013/06/cookie-forcing-protectio... https://github.com/mozilla/django-session-csrf https://github.com/mozilla/django-session-csrf seems ok, should be default
    - JshWright 13y ago
      "i am not sure how it works in Django" Perhaps you should do a little research before proclaiming things insecure?
      - homakov 13y ago
        bitbucket is vulnerable > django has a problem if it's not enough: some websites from http://www.djangosites.org/ http://www.djangosites.org/ are vulnerable > django has a problem
  - 13y ago
deleted 13y ago
[deleted]
jacobian 13y ago
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
donaldstufft 13y ago
Django's CSRF protection is perfectly fine other than issues with BREACH. In any case that you can edit the CSRF token you already can execute a much stronger attack (MITM, XSS, etc). If you have a way to set your own arbitrary cookie that doesn't require a much work attack that already includes the ability to do arbitrary requests without them needing to be cross origin then I heartily suggest you report it.
- homakov 13y ago
  > In any case that you can edit the CSRF token you already can execute a much stronger attack (MITM, XSS, etc). MITM is not a problem for HTTPS, but it can force cookies. Subdomain can do same thing. These preconditions are common
  - donaldstufft 13y ago
    A browser will accept cookies from a HTTP response on a site that has HSTS set? A CSRF request from a plaintext subdomain would not include a header and would fail Django's CSRF for lacking a referrer header (Strict referrer checking only available under HTTPS). Further more even a subdomain under TLS would fail to have the same origin. A subdomain can set cookies this is true. This requires a XSS on the subdomain or allowing plaintext responses on subdomains. If you do not ensure both of these then besides being able to set (or in the case of XSS, read) the CSRF token you can also fixate the session, steal the session, preform a DoS using the size of the cookie, etc. The solution is forced TLS with HSTS and includeSubdomains.
    - homakov 13y ago
      hm, how can XSS on subdomain: "steal the session, preform a DoS using the size of the cookie"
      - homakov 13y ago
        >The solution is forced TLS with HSTS and includeSubdomains. that's true. Few questions: 1) does django provide HSTS header by default? didn't find it in codebase 2) does django has includeSubdomains? bitbucket doesn't have it 3) it is still vulnerable to subdomain-XSS tossing. taking into account all possible ways to replace the token I think it's django's duty to couple it with session (whatever it is in django) by default. What do you think, should it stay semi manual?

im a rabbit

by homakov 13y ago

im a rabbit

Rails is not vulnerable to cookie forcing btw. But your authentication can be (Devise bug http://blog.plataformatec.com.br/2013/08/csrf-token-fixation-attacks-in-devise/ http://blog.plataformatec.com.br/2013/08/csrf-token-fixation... )

JshWright 13y ago

>And i was trying to report it, but didn't find a contact/email. How hard did you try? Django uses the industry standard security@ address for reporting security issues. A quick googling results in this page pretty easily: https://docs.djangoproject.com/en/1.5/internals/security/ https://docs.djangoproject.com/en/1.5/internals/security/ EDIT: I described the link as 'first' in the Google results, but that was because Google was being helpful and promoting a page I've visited a lot before... In reality, it's a few links down.

homakov 13y ago
1) open https://www.djangoproject.com/ https://www.djangoproject.com/ 2) find /contact/, /email/, user group
- steveklabnik 13y ago
  I've never really looked at Django's site before, picked 'community' on the upper right, and it says > Report potential security issues in Django via private email to > security@djangoproject.com, and not via Django's Trac instance or the > django-developers mailing list
- JshWright 13y ago
  The community page (where all the mailing lists and contact addresses are listed) say: >Report potential security issues in Django via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers mailing list

homakov 13y ago

P.S. i am not into django, but if you have a clue how to contact authors... please tell them to put CSRF token into session cookie. It must be fixed in the first place, BREACH is 100 times harder and longer, while cookie forcing is completely viable attack with active MITM. Or perhaps it was fixed? I checked it on bitbucket the last time..

jacobian 13y ago
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 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.
- homakov 13y ago
  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-protection-made-easy.html http://homakov.blogspot.com/2013/06/cookie-forcing-protectio... https://github.com/mozilla/django-session-csrf https://github.com/mozilla/django-session-csrf seems ok, should be default
  - JshWright 13y ago
    "i am not sure how it works in Django" Perhaps you should do a little research before proclaiming things insecure?
    - homakov 13y ago
      bitbucket is vulnerable > django has a problem if it's not enough: some websites from http://www.djangosites.org/ http://www.djangosites.org/ are vulnerable > django has a problem
- 13y ago

deleted 13y ago

[deleted]

jacobian 13y ago

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

donaldstufft 13y ago

Django's CSRF protection is perfectly fine other than issues with BREACH. In any case that you can edit the CSRF token you already can execute a much stronger attack (MITM, XSS, etc). If you have a way to set your own arbitrary cookie that doesn't require a much work attack that already includes the ability to do arbitrary requests without them needing to be cross origin then I heartily suggest you report it.

homakov 13y ago
> In any case that you can edit the CSRF token you already can execute a much stronger attack (MITM, XSS, etc). MITM is not a problem for HTTPS, but it can force cookies. Subdomain can do same thing. These preconditions are common
- donaldstufft 13y ago
  A browser will accept cookies from a HTTP response on a site that has HSTS set? A CSRF request from a plaintext subdomain would not include a header and would fail Django's CSRF for lacking a referrer header (Strict referrer checking only available under HTTPS). Further more even a subdomain under TLS would fail to have the same origin. A subdomain can set cookies this is true. This requires a XSS on the subdomain or allowing plaintext responses on subdomains. If you do not ensure both of these then besides being able to set (or in the case of XSS, read) the CSRF token you can also fixate the session, steal the session, preform a DoS using the size of the cookie, etc. The solution is forced TLS with HSTS and includeSubdomains.
  - homakov 13y ago
    hm, how can XSS on subdomain: "steal the session, preform a DoS using the size of the cookie"
    - homakov 13y ago
      >The solution is forced TLS with HSTS and includeSubdomains. that's true. Few questions: 1) does django provide HSTS header by default? didn't find it in codebase 2) does django has includeSubdomains? bitbucket doesn't have it 3) it is still vulnerable to subdomain-XSS tossing. taking into account all possible ways to replace the token I think it's django's duty to couple it with session (whatever it is in django) by default. What do you think, should it stay semi manual?