On Mon, 2010-09-06 at 18:46 +0200, Patryk Zawadzki wrote: > 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/";). Almost everything in this discussion and all your misconceptions are covered here: http://code.djangoproject.com/wiki/CsrfProtection For HTTP (not HTTPS), MitM attacks are out of scope for our CSRF protection, because a MitM sees everything in the clear and will easily be able to defeat any defences we put up. Your suggested alterations do nothing to stop that. In the context of HTTPS, the Referer header check does indeed add a necessary and effective protection. The nature of a CSRF attack is that the attacker has to gets the *user's* browser to make the request, not the attacker's. The curl command line says nothing at all - I'm well aware that the attacker can do that from their own machine if they want to, but it won't do them any good! I could not understand how you thought that showing a curl command line is at all relevant. A MitM cannot tamper with requests that are sent over SSL. The only exception to this is that if HTTP -> HTTPS POST requests are allowed, the MitM can indeed generate any request they like and get the user's browser to send it, with potentially damaging consequences. To stop this we, we simply refuse HTTP -> HTTPS POST requests. In the context of an HTTPS request from a browser, we can indeed trust the Referer header since no-one can tamper with it in transit, and the MitM will not be able to convincingly send the user's browser a page that looks like it comes from https://example.com. Please distinguish between the HTTP/HTTPS context if you've still got questions. Luke -- A mosquito cried out in pain: "A chemist has poisoned my brain!" The cause of his sorrow was para-dichloro- diphenyltrichloroethane Luke Plant || http://lukeplant.me.uk/ -- 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.
