Allow skipping CSRF check for Referer header

[Aaron Hill]

Currently, Django's CSRF middleware will reject any 'non-safe' HTTPS request that lacks a Referer header: ​https://github.com/django/django/blob/22e8ab02863819093832de9f771bf40a62a6bd4a/django/middleware/csrf.py#L242

However, some users may prevent their browsers from sending the Referer header, due to privacy concerns. These users are unable to submit 'non-safe' requests (e.g. POST requests) on HTTPS-enabled Django-powered website that use CSRF protection.

For some websites, checking the Referer header may provide no added security benefit. For example, an HSTS-preloaded website which controls all of its subdomains has nothing to gain from this check - there are no untrusted subdomains which can mount an attack, and HSTS prevents an HTTP MITM attack.

To allow these websites to provide more flexibility to their users, Django should support disabling this CSRF Referer check. This could be done through a new setting, e.g. ' CSRF_REFERER_CHECK' (defaulting to 'True' to avoid breaking existing sites).

[Adam Johnson]

I also discovered a similar problem recently when deploying the "Referrer-Policy" header using James Bennett's library: https://django-referrer-policy.readthedocs.io/en/stable/ . Initially I opted for 'no-referrer' as I figured it was the most secure, but since this check is only done on HTTPS-enabled sites, it wasn't discovered that all forms were broken until production where HTTPS is used.

I think the existence of Referrer-Policy bolsters the argument for this option, since some users might want to use 'no-referrer'. And in fact the current check presumes the Referrer Policy is left at the default, no-referrer-when-downgrade , and I'm pretty sure other values than no-referrer break it as well.

+1 from me (I wonder if it could even be automatic if HSTS is enabled?)

--
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/bcc04352-cd39-485a-83ad-49d0608d6ccd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[Florian Apolloner]

Wouldn't one alternative be checking the Origin header? It appears though that all browsers support it with the sad exception that it is still behind a feature flag in Firefox. :/ (https://bugzilla.mozilla.org/show_bug.cgi?id=1424076)

[Adam Johnson]

I would think that feature flag rules it out for a long time?

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5c89439f-1f3c-44ff-99a6-708ae5c42684%40googlegroups.com.

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

--

Adam

[Florian Apolloner]

Not neccessarily, one could still use the Origin header in cases where software strips the Referer and if you set the Referrer-Policy to same-origin you shouldn't have problems with firefox either.

[Collin Anderson]

Aas a data point, I've customized my csrf checking to skip the referrer checking if there's a correct origin header. Though yes, it doesn't work in some browsers. (I haven't set up Referrer-Policy so that hasn't been an issue for me yet.)

I think it's worth mentioning too that same-site cookies are starting to get a lot of browser support and could be an alternative csrf protection: https://caniuse.com/#feat=same-site-cookie-attribute

>For some websites, checking the Referer header may provide no added security benefit. For example, an HSTS-preloaded website which controls all of its subdomains has nothing to gain from this check - there are no untrusted subdomains which can mount an attack, and HSTS prevents an HTTP MITM attack.

> To allow these websites to provide more flexibility to their users, Django should support disabling this CSRF Referer check. This could be done through a new setting, e.g. ' CSRF_REFERER_CHECK' (defaulting to 'True' to avoid breaking existing sites).

I think this could make sense as long as it's well documented what the requirements are to stay secure, and maybe a clear example of the attack vector.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d79cf158-c3da-402e-a3a7-5260e79317c5%40googlegroups.com.