On 03/08/13 23:57, Shai Berger wrote: > This would work exactly like it works today, except with signed cookies. That > is, the "user specific element" is the cookie. CSRF is about tricking the > user > into submitting a request designed out of the site -- an attacker can't just > set (or read) cookies on a user's browser, nor read tokens from the page, > under the assumptions we're making about the general setup.
A signed cookie is not "user specific" in the sense I meant. It is only user specific if it cannot be transferred to another user and still work. But a signed CSRF cookie, with a matching token, can indeed be transferred to another user (unless the signed data includes the session or user id, for instance). In this case, signing the cookie only adds protection if the SECRET_KEY is changed after the exploit. It doesn't stop the attacker getting and using a valid CSRF cookie/token in the first place. Luke -- "DO NOT DISTURB. I'm disturbed enough already." Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
