Being someone who disables the referrer header in my browser, I was surprised to find I can't use Django's CSRF middleware with HTTPS but without a referrer header. Trying to find out why, I came across the following:
"The attacker can set the CSRF cookie using Set-Cookie, and then supply a matching token in the POST form data. Since the site does not tie the session cookies to the CSRF cookies, it has no way of determining that the CSRF token + cookie are genuine (doing hashing etc. of one of them will not work, as the attacker can just get a valid pair from the site directly, and use that pair in the attack)." https://code.djangoproject.com/wiki/CsrfProtection#Sessionindependentnonce I (think I) understand what this is supposed to prevent: an attacker has hijacked an HTTP connection. He sets his own CSRF cookie so that he can provide a fake form to the user with his CSRF token, and then the form gets submitted over HTTPS. What I don't understand is why this attack needs to be defended against. If the attacker has hijacked an HTTP connection, he can just obtain the user's session cookie and produce his own HTTPS requests with whatever referrer header he wants (the sort of attack that Firesheep (http://en.wikipedia.org/wiki/Firesheep) does). Do I misunderstand the attack that referrer checking is supposed to defend against, or are there situations in which the CSRF cookie attack is significantly easier than just stealing the session cookie? -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/ZXY-CUqualAJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
