On 11:06 +0100 / 23 Jul, Luke Plant wrote: > On 23/07/12 08:07, Rohan Jain wrote: > > ###CSRF Cookies (Time signed): > > > > - A random token generated by the server stored in the browser cookies. For > > verification, every non get request will need to provide a signed > > version of > > the same token. This can then be verified on the browser side. > > - This can be implemented by adding signing to the existing csrf token > > system, > > using the signing framework. > > - A conventional method of CSRF checks, all the major frameworks have > > similar > > systems. > > - Signing takes care of the side effects due to cross domain behaviour of > > cookies. > > - Cons: > > > > - Relies on the browser cookies system, which introduces insecurities. > > - Can be broken easily by having a parallel legitimate session, which > > gives > > a valid token, signature pair. This generator can then be used in MITM > > attacks. > > I don't understand the motivation for this part. Could you describe the > attack scenarios where this method improves our security with respect to > the current system?
With this, attacker won't be able to directly set arbitrary tokens on other sub domains through cookies, they will need a signature of the token with the form which is to be verified against the cookie. Plus it also puts a limit on the duration a token stays valid on the server side. Yes, still with this, someone can spoof the whole pair using a separate legitimate session. So really it doesn't make it completely secure, just makes it little difficult for the attacker. If it weren't for the possibility of attacker injecting cookies from other subdomains, I think CSRF token should be a fine check for CSRF. That is why I am siding on adding referer checking in case of non https scheme requests too. -- Thanks Rohan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
