On Mon, 2010-09-06 at 21:11 +0200, Patryk Zawadzki wrote: > See above, I'm concerned about the case when the attacker is able to > perform a replay attack. If you validate CSRF against the client's IP > (and possibly against a TTL field¹), you effectively prevent that type > of attack. If the CSRF tokens were stored in the database (much like > sessions are), you'd gain additional security of all tokens expiring > after one use (or TTL reached).
Replay attacks? 1) You didn't mention this before 2) This is out of scope for what the CSRF defences are about 3) SSL protects us: http://stason.org/TULARC/security/ssl-talk/4-1-Does-SSL-protect-users-from-replay-attack-by-eavesdropp.html If you are talking about the session cookie being stolen because it is leaked over HTTP, that again is out of scope for CSRF - it can only be addressed by using a secure cookie (SESSION_COOKIE_SECURE). > > 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. > > The MitM can also trick the user into POSTing same data over HTTP and > forge a HTTPS request of his own. That's why I propose using a > separate, secure CSRF cookie (using a different name) for HTTPS > requests. It doesn't matter what the name of the cookie is, the attacker can still set a cookie with that name. > > 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. > > I believe you can use mere cookies to prevent this (see above) and > keep the site working for people who don't and can't send Referer > headers. I don't think so, for reasons given below. > > ¹ Consider the following example. It was based on the code I wrote to > handle the new Facebook API so it might be a bit of an overkill but it > shows it's possible. A simpler solution would be to return (TTL + ':' > + md5(token + user_ip + secret_key + TTL)). > You are proposing adding IP address as a means of identifying a user, but that is a bad idea on two counts: 1) The attacker can have the same (public) IP address as the victim if they are both behind the same firewall, and this will in fact be one of the most practical ways to launch a MitM + CSRF attack on HTTPS. 2) There is no guarantee that a user has a single IP addresses for the duration of his session. My mobile phone's IP address can change quite quickly. Once you've removed the IP address from the equation, the only barrier you are adding is a TTL. However, that is a very small barrier - any view that returns a POST form can easily be parsed to retrieve a valid CSRF token - we hand out valid CSRF tokens very easily, whether over HTTP or HTTPS. The attacker can use a token retrieved in that way. There is nothing to connect the CSRF token to the user, and this is *by design*, because: 1) In Django we have no way to identify a user. We don't want to rely on the session framework, because a site might not be using it. 2) Even if a site is using the session framework, we've had issues in the past with stale CSRF tokens caused by session cycling. Almost everything I've said to this point is explained in the document I linked before. 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.
