On Aug 6, 2013, at 12:16 PM, Tom Scrace <t.scr...@gmail.com> wrote: > On Tuesday, August 6, 2013 3:42:01 PM UTC+1, Jacob Kaplan-Moss wrote: > > We plan to take steps to address BREACH in Django itself, but in the meantime > we recommend that all users of Django understand this vulnerability and take > action if appropriate. > > > Would randomizing the CSRF token on each request be the correct way to fix > this in Django?
This incurs the cost that every request to Django invalidates all existing CSRF tokens (meaning if you start filling out a form, and then open another form in a different tab the first form will send an error) 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. There are a few possible solutions each with their own drawbacks. Such as secret hiding or disabling compression only for pages that have CSRF (or other secret output). > > Tom > > -- > 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > > ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
