Hacker News Reader

Comment by homakov | Hacker News Reader

im a rabbit

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

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?

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

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.

1) open https://www.djangoproject.com/ 2) find /contact/, /email/, user group

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

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

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.

> 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

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.

hm, how can XSS on subdomain: "steal the session, preform a DoS using the size of the cookie"

>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?

1) Not currently (and it's unlikely to be able to do so) there's an addon to add it which has been talked about getting it into core. I do believe it's documented to use HSTS and TLS if you want your site secured and recommends the ddon.

2) The above addon does have it. I have no idea what bitbucket does.

3) Not sure I understand what this means, you mean if there is a valid XSS on a subdomain?

Decoupling CSRF and Sessions has been a requirement for us for awhile now. We've spoken a little bit about optionally coupling them where if you have the session framework enabled it will couple them but if you don't it falls back on the current method.

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

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.

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

"i am not sure how it works in Django"

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

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

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.

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

Reply on news.ycombinator.com