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?)

On Fri, 9 Nov 2018 at 21:31, Aaron Hill <aa1ron...@gmail.com> wrote:

> 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).
>
> --
> 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 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
> <https://groups.google.com/d/msgid/django-developers/bcc04352-cd39-485a-83ad-49d0608d6ccd%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM30D7GhDuLa6JFbgMgBZC5FqmFFDf%3D%3DhFvQbXdhXdPdgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to