On Mon, Sep 6, 2010 at 6:34 PM, Luke Plant <l.plant...@cantab.net> wrote: > OK, that does it. I call 'troll'. If you're not trolling, my > apologies, but I have run out of energy trying to explain this to you.
I'm still waiting for you to explain anything. You said you were afraid of a third-party injecting cookies over HTTP that would be then sent over HTTPS. I replied by telling you that currently it does not have to do any injecting as it can just forge both the cookie and the token when doing a malicious POST (attaching any other cookies and post data needed to DoEvil™) -- current CSRF implementation does not stop such attacks at all. Moreover I proposed a more secure cookie header that is both immune to stealing (as it's calculated and checked using your IP address) and forging (as you no longer ask the client to send you the same string twice, both post payload and headers being in plaintext). The curl example was there to illustrate the problem of the current implementation: a malicious client or proxy is free to replace both the cookie and post payload and CSRF will validate. If I can capture a HTTP request (the MitM case) and read the headers, it's just a matter of taking the cookies, replacing the CSRF token cookie with "foo" and I am free to make any request on the site I want for as long as I want. Requiring me to send a "Referer" header is a mild inconvenience at most (just send "https://domain.com/";). Your only reply is calling me a troll. -- Patryk Zawadzki -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
