Re: Why is the CSRF template context processor hardcoded?
Hi Aymeric,
I agree there is no security vulnerability, because the middleware
defaults to safe. That comment should be fixed.
The hard-coding was put there basically to make it easier to use, first
for the case of simple migration instructions when this CSRF protection
was introduced/changed, and secondly for the ongoing case - anything we
could do to streamline the instructions and minimise things that go
wrong was considered a good thing, so that we avoid the whole "just
disable the CSRF middleware" temptation.
Luke
On 20/09/14 22:16, Aymeric Augustin wrote:
> Hello,
>
> I'm wondering why django.template.context defines:
>
> # We need the CSRF processor no matter what the user has in their settings,
> # because otherwise it is a security vulnerability, and we can't afford to
> leave
> # this to human error or failure to read migration instructions.
> _builtin_context_processors = ('django.core.context_processors.csrf',)
>
> and then forcibly prepends it to settings.TEMPLATE_CONTEXT_PROCESSORS.
>
> If the template context processor was missing, {% csrf_token %} wouldn't
> output anything in templates. Then it would be impossible to submit forms,
> but that would be a bug.
>
> The CSRF context processor even has a branch that returns NOTPROVIDED. {%
> csrf_token %} specifically tests for this case and doesn't output anything
> when it happens.
>
> So I fail to find the security vulnerability the comment talks about. I
> didn't find the answer in:
> -
> https://github.com/django/django/commit/8e70cef9b67433edd70935dcc30c621d1e7fc0a0
> - https://code.djangoproject.com/ticket/9977
> - https://code.djangoproject.com/wiki/CsrfProtection
>
> Does anyone remembers the reasoning?
>
> Thanks,
>
--
"Cross country skiing is great if you live in a small country."
(Steven Wright)
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/542D1670.1010306%40cantab.net.
For more options, visit https://groups.google.com/d/optout.
Re: Why is the CSRF template context processor hardcoded?
Hi Aymeric,
As I recall, the reasoning was:
a) CSRF should almost always be on anyway
b) The cost of having the CSRF token in place if you actually aren't using
CSRF was pretty low
c) Template documentation essentially says "put {% csrf_token %} in your
template always; if it's hardcoded, there's no "if CSRF is enabled"
question required.
d) If templates are being distributed as part of the third party package,
you want to make sure they work out of the box
e) We didn't want have two moving parts to enable it (middleware *and*
context processor).
Russ %-)
On Sun, Sep 21, 2014 at 5:16 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> I'm wondering why django.template.context defines:
>
> # We need the CSRF processor no matter what the user has in their settings,
> # because otherwise it is a security vulnerability, and we can't afford to
> leave
> # this to human error or failure to read migration instructions.
> _builtin_context_processors = ('django.core.context_processors.csrf',)
>
> and then forcibly prepends it to settings.TEMPLATE_CONTEXT_PROCESSORS.
>
> If the template context processor was missing, {% csrf_token %} wouldn't
> output anything in templates. Then it would be impossible to submit forms,
> but that would be a bug.
>
> The CSRF context processor even has a branch that returns NOTPROVIDED. {%
> csrf_token %} specifically tests for this case and doesn't output anything
> when it happens.
>
> So I fail to find the security vulnerability the comment talks about. I
> didn't find the answer in:
> -
> https://github.com/django/django/commit/8e70cef9b67433edd70935dcc30c621d1e7fc0a0
> - https://code.djangoproject.com/ticket/9977
> - https://code.djangoproject.com/wiki/CsrfProtection
>
> Does anyone remembers the reasoning?
>
> Thanks,
>
> --
> Aymeric.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9EFBA6B8-F6F3-4DD4-9911-2B13906BEC2C%40polytechnique.org
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAJxq848uH6B_GmM58FLX1pSw8ciXW%2BK-MqY%2BGsnMQdzB8sA2Rw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Why is the CSRF template context processor hardcoded?
Hello,
I'm wondering why django.template.context defines:
# We need the CSRF processor no matter what the user has in their settings,
# because otherwise it is a security vulnerability, and we can't afford to leave
# this to human error or failure to read migration instructions.
_builtin_context_processors = ('django.core.context_processors.csrf',)
and then forcibly prepends it to settings.TEMPLATE_CONTEXT_PROCESSORS.
If the template context processor was missing, {% csrf_token %} wouldn't output
anything in templates. Then it would be impossible to submit forms, but that
would be a bug.
The CSRF context processor even has a branch that returns NOTPROVIDED. {%
csrf_token %} specifically tests for this case and doesn't output anything when
it happens.
So I fail to find the security vulnerability the comment talks about. I didn't
find the answer in:
-
https://github.com/django/django/commit/8e70cef9b67433edd70935dcc30c621d1e7fc0a0
- https://code.djangoproject.com/ticket/9977
- https://code.djangoproject.com/wiki/CsrfProtection
Does anyone remembers the reasoning?
Thanks,
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/9EFBA6B8-F6F3-4DD4-9911-2B13906BEC2C%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
