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.



On Sat, Nov 10, 2018 at 10:47 AM Florian Apolloner <f.apollo...@gmail.com>
wrote:

> 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.
>
> On Saturday, November 10, 2018 at 1:42:41 PM UTC+1, Adam Johnson wrote:
>>
>> I would think that feature flag rules it out for a long time?
>>
>> On Sat, 10 Nov 2018 at 09:52, Florian Apolloner <f.apo...@gmail.com>
>> wrote:
>>
>>> 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)
>>>
>>> On Saturday, November 10, 2018 at 1:03:08 AM UTC+1, Adam Johnson wrote:
>>>>
>>>> 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 <aa1r...@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-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
>>>>> <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-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/5c89439f-1f3c-44ff-99a6-708ae5c42684%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/5c89439f-1f3c-44ff-99a6-708ae5c42684%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/d79cf158-c3da-402e-a3a7-5260e79317c5%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/d79cf158-c3da-402e-a3a7-5260e79317c5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7EQVq4cpxDtHFNzLjaJotngOmw8G3VB%2BARmcEE3P09%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to