Many thanks for the reply. This is perfect and I can get back to the pen-testers now that I fully understand the issue.
Regards, Gruff On Thursday, 23 August 2012 02:04:56 UTC+1, Paul McMillan wrote: > > 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 > <gruf...@gmail.com<javascript:>> > 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-d...@googlegroups.com<javascript:>. > > > To unsubscribe from this group, send email to > django-develop...@googlegroups.com <javascript:>. > > 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 view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/iCTp7O2WqN4J. 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.