Add a setting for customizing the CSRF token name?

[Tim Graham]

Do you think it's worth a new setting to allow customizing the CSRF token name ('csrfmiddlewaretoken')?

It was proposed 9 years ago in https://code.djangoproject.com/ticket/12738 and closed as wontfix absent some justification.

It was again proposed a few days ago in https://github.com/django/django/pull/10305 with the rationale:

Wappalyzer identifies Django application with "csrfmiddlewaretoken" input name.
https://github.com/AliasIO/Wappalyzer/blob/master/src/apps.json#L2471

I guess the idea is trying to obscure the fact that a site runs Django for some "security by obscurity."

[Aymeric Augustin]

Hello,

Perhaps we could reuse settings.CSRF_COOKIE_NAME there instead of the hardcoded "csrfmiddlewaretoken"? That would meet the stated goal without introducing a new setting. Also it feels sensible to me to use the same name for the input and the cookie.

There would be some hiccups — 403 errors on legitimate requests — when upgrading a website to a new version of Django that includes this change. To avoid that, we could implement a backwards-compatibility shim that we would keep for one major version.

Best regards,

-- 

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/01b25887-823e-4008-9ad4-51f80e7c2590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ramiro Morales]

Hello,

I'd be in favor of what's proposed.

Slightly related, this made me remember I had some note about proposing we add either to the Security or the Deployment checklist documents suggestions about (also) customizing the CSRF_COOKIE_NAME, LANGUAGE_COOKIE_NAME and SESSION_COOKIE_NAME settings. to make identifying Django is being used harder.

(This is related to what Aymeric mentions) It's easier this kind of customization is performed before the initial deployment to avoid the hassle caused by trying to change them once a site is in production, that's why I think it's a good idea to make developers/deployers aware they have these choices at that point.

Regards,

--

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-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/01b25887-823e-4008-9ad4-51f80e7c2590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Ramiro Morales
@ramiromorales

[Adam Johnson]

I've thought about this a bit, especially back in the context of tracking how many sites use Django. Besides the CSRF token input name there are probably tens to hundreds of little signals that a site runs Django, e.g. the presence of /admin/, CSRF/session cookie presence/size, APPEND_SLASH, default 400/403/404/500 handler responses, default form widget validation errors, or even the presence of *any* hidden input in a form with a random string that looks like a django CSRF token (i.e. if the name is changed it's probably still detectable). Not to mention popular third party packages, e.g. Sentry inserts a predictable HTML tag.

I'm not sure introducing this change because one analyzer tool currently picks up on the signal is a great reason, only a little bit of potential obscurity is gained. Especially since it's a problem for big sites deploying it, as Aymeric points out we'd need to write a shim.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5796AA81-96EC-418E-A174-D11FAC28704A%40polytechnique.org.

For more options, visit https://groups.google.com/d/optout.

--

Adam

[Shai Berger]

On Sat, 18 Aug 2018 21:27:02 +0200
Adam Johnson <m...@adamj.eu> wrote:

> I'm not sure introducing this change because one analyzer tool
> currently picks up on the signal is a great reason, only a little bit
> of potential obscurity is gained. Especially since it's a problem for
> big sites deploying it, as Aymeric points out we'd need to write a
> shim.
>

+1.

On Sat, 18 Aug 2018 at 18:31, Aymeric Augustin
<aymeric....@polytechnique.org> wrote:
> Perhaps we could reuse settings.CSRF_COOKIE_NAME there instead of the
> hardcoded "csrfmiddlewaretoken"? That would meet the stated goal
> without introducing a new setting. Also it feels sensible to me to
> use the same name for the input and the cookie.

This sort of reuse feels wrong to me -- if we do allow changing the
name, I'd be -0.5 on reusing the setting and tying these two names to
eachother.