Hi, On Sunday 04 August 2013 01:26:58 Luke Plant wrote: > On 28/07/13 00:12, Shai Berger wrote: > > > > a) Use a signed cookie for csrftoken -- using Django's existing signing > > facility[4], this means signing the cookie with the SECRET_KEY from the > > settings; so that an attacker cannot set arbitrary cookies, and changing > > the SECRET_KEY after a compromise immeiately invalidates csrftoken > > cookies. > > I don't understand how this is supposed to work. For most Django sites, > it is trivial to get a page from a site and extract a CSRF token and/or > CSRF cookie value. (The same-origin policy means that you can't do it > client-side from a different website, but a tiny server-side script can > do it). An attacker can use this to forge a token or cookie that looks > like it was signed by the Django site, because it was. > > If SECRET_KEY is changed, the attacker can just get a new signed value. > > The only way this would work is if there is a user specific element that > stops the attacker from getting a CSRF token that will work on the > victim. To do this, you have to go back to tying CSRF tokens to the > session, or something equivalent. > 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.
Shai. -- 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.
