Hi Gruffudd, If the cookie were set to expire at browser close, it would cause CSRF errors for users who closed a browser (or bookmarked a page with a form on it) and then loaded that page from a browser cache and submitted the form. I'm ambivalent about whether this use case is worth supporting (it may be important on mobile devices, for example), but I don't believe that setting the cookie to expire on browser close provides much security benefit to an otherwise properly configured site (HTTPS, HSTS, etc.).
Django's CSRF implementation differs[1] from many others which store CSRF information alongside session information on the server. The CSRF mechanism functions by matching a token provided in a form with a token provided as a cookie in the browser. If you set the cookie to 'zzz', it will still function perfectly well. The security comes from the fact that an attacker cannot set the cookie, not that it happens to contain any specific cryptographic value. If the concern is that an attacker could access a user's physical computer between sessions and steal a CSRF token, setting it to expire at browser close would not prevent an attacker from inserting a cookie of known value that would be used during the next session. I'm not convinced we can secure the tokens of a user whose computer has been physically accessed by an attacker. Still, if it can be convincingly demonstrated that setting the cookie to expire at browser close would not break existing use cases (mobile browsers are my chief concern) I'd be open to changing the default behavior. We generally consider it a bug if any non-malicious user can, through innocent behavior, trigger the CSRF warning. -Paul [1] Django's CSRF implementation usually sets off all kinds of false alarms in most pen-tester's tools, since it doesn't work exactly the same way other implementations do, and isn't tied to the session cookie. On Tue, Aug 21, 2012 at 3:53 PM, Gruffudd Williams <gruff...@gmail.com> wrote: > The results of a recent penetration test brought up the issue of the use of > persistent cookies, specifically the CSRF cookie which has an expiry date one > year in the future. > > The rationale given was that since the cookie is stored on the hard drive > then it is theoretically possible to get hold of it between a user's sessions. > > The question is, does the csrf cookie really need to be persistent at all? I > can't see that setting an expiry adds to the security model. > If it was made non-persistent then the only difference is that the cookie > would be re generated for each new browser session, which means it would be > generated more often than if the cookie was persistent, but is this an issue? > > Perhaps I'm missing something, but I'd be interested to learn the reasons why > it was implemented with a persistent cookie. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/N4a1LKzUIYoJ. > 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. > -- 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.
