On 6 Aug 2013, at 12:34 PM, Tim Chase wrote: > On 2013-08-06 12:53, Donald Stufft wrote: >> This incurs the cost that every request to Django invalidates all >> existing CSRF tokens [....] OR requires you to store a separate CSRF token >> for each >> request and look up the submitted CSRF token in that set of stored >> tokens. > > After through the PDF, my understanding that it requires the token > to be constant across all requests. One might be able to mitigate it > a bit by randomly inserting values into the CSRF token that then get > stripped back out before being checked. So the actual transmitted > value changes every time (per 3.4 in the PDF), but the server knows > how to strip the random junk back out.
I had a similar thought. More generally: Django could pick a random nonce and send nonce + F(nonce, csrftoken) where F can be any of a lot of functions (inserting half the nonce before and half after the csrftoken; XORing the csrftoken with the nonce; doing a full AES encryption; computing SHA1(nonce + token); etc). Django would either reverse the process upon receipt to recover the original csrftoken, or if a nonreversible F() is used, it could use the returned nonce to compute F(nonce, csrftoken) and compare that with the value sent by the client. As long as the function F() is not something that the compressor can "see through" in any way, this should prevent BREACH/CRIME style traffic-size attacks. Does Django need to do something similar to protect session identifiers? -- 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.
