#32800: CsrfViewMiddleware unnecessarily masks CSRF cookie
-------------------------------------+-------------------------------------
Reporter: Chris Jerdonek | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: CSRF | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Chris Jerdonek:
Old description:
> I noticed that `CsrfViewMiddleware` unnecessarily masks the CSRF cookie.
> See, for example:
> https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L91
>
> My understanding of the [http://breachattack.com/ BREACH attack] is that
> the vulnerability comes from not masking the CSRF token in the response
> body (e.g. what is included in the HTML). Masking the cookie itself
> doesn't help with this. (Django also
> [https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L308-L309
> doesn't change the mask] of the cookie with each request, so the mask
> wouldn't help in this regard anyways.)
>
> Some advantages of not masking the cookie are: It would simplify the code
> in `CsrfViewMiddleware` because it would remove some complexity and
> operations that aren't needed for security. Currently, masking the CSRF
> cookie is a red herring for someone wanting to understand the various
> security features. Also, not masking the cookie would make requests and
> responses smaller when `CSRF_USE_SESSIONS` is false or when true and
> cookie-based sessions are used. This is because masking doubles the
> length of the string.
New description:
I noticed that `CsrfViewMiddleware` unnecessarily masks the CSRF cookie.
See, for example:
https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L91
My understanding of the [http://breachattack.com/ BREACH attack] is that
the vulnerability comes from not masking the CSRF token in the response
body (e.g. what is included in the HTML). Masking the cookie itself
doesn't help with this. (Django also
[https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L308-L309
doesn't change the mask] of the cookie with each request, so the mask
wouldn't help in this regard anyways.)
Some advantages of not masking the cookie are: It would simplify the code
in `CsrfViewMiddleware` because it would remove some complexity and
operations that aren't needed for security. Currently, masking the CSRF
cookie is a red herring for someone wanting to understand the various
security features. Also, not masking the cookie would make requests and
responses smaller when `CSRF_USE_SESSIONS` is false or when true and
cookie-based sessions are used. This is because masking doubles the length
of the string.
This can be changed fairly easily while (1) continuing to respect masked
cookie values, and (2) not forcing session stores to update their cookie
in its unmasked form if they are currently storing it masked.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32800#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.53b2ff1cc1a2b94198f4d2b0c8e05cb9%40djangoproject.com.
