Re: Why is CSRF cookie persistent?

[Gruffudd Williams]

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 
>  
> 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. 
>
> > To unsubscribe from this group, send email to 
> django-develop...@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 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.

Re: Why is CSRF cookie persistent?

[Paul McMillan]

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  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.

Why is CSRF cookie persistent?

[Gruffudd Williams]

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.