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.

Reply via email to