Hi Tim,
Thanks for working on this. I've put together some replies to your points
here.
On #1 - I think it's legitimate to have `CSRF_TRUSTED_ORIGINS` require the
schemes. I think the setting should have included them all along, since a
scheme is part of the definition of an origin. It's backwards incompatible
but the workaround when supporting multiple Django versions would be fairly
simple, for example:
```
CSRF_TRUSTED_ORIGINS = [
"example.com",
]
if django.VERSION >= (4, 0):
CSRF_TRUSTED_ORIGINS = [f"https://{origin}"; for origin in
CSRF_TRUSTED_ORIGINS]
```
We could also provide temporary, immediately-deprecated support for origins
without schemes by interpreting them as "http" and "https" by default.
I didn't add the regex support to django-cors-headers and I don't like it,
since a malformed regex could cause a security hole.
On #2 - see above, no new setting.
On #3 - agreed. This will allow sites to drop the Referer header completely
for privacy, if they want, by setting SECURE_REFERRER_POLICY =
'no-referrer'.
On #4 - the "privacy-sensitive contexts" listed on OWASP all seem to be
things that would only trigger GET requests. It might even be legitimate to
fail CSRF if origin is null, since CSRF is skipped for GET's.
Thanks,
Adam
On Tue, 12 Jan 2021 at 12:18, Tim Graham <timogra...@gmail.com> wrote:
> OWASP Cheat Sheet says, "It is important to note that [the SameSite
> Cookie] attribute should be implemented as an additional layer *defense
> in depth* concept. This attribute protects the user through the browsers
> supporting it, and it contains as well 2 ways to bypass it as mentioned in
> the following section
> <https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.3.7.1>.
> This attribute should not replace having a CSRF Token. Instead, it should
> co-exist with that token in order to protect the user in a more robust way."
> On Tuesday, January 12, 2021 at 5:44:56 AM UTC-5 jacob...@gmail.com wrote:
>
>> Shouldn't we consider to put the CSRF token onto the deprecation list
>> anyway?
>> All browsers released later than 2017 support the 'SameSite' cookie
>> attribute <https://caniuse.com/?search=SameSite>, making the CSRF token
>> obsolete.
>> I don't know what kind of policy the Django Project follows in
>> deprecating browsers, but we can expect
>> that IE, Edge<16, Safari<12, Chrome<51, etc. won't play a major role when
>> Django-4 (or maybe 5?) will be released.
>>
>> Strictly speaking, the CSRF token is a hack/workaround which in an ideal
>> world shouldn't be required anyway.
>> And it always has been painful having to fiddle with it in my Django Form
>> Views.
>>
>> Just my two cents,
>> Jacob
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/915ff447-502e-45c2-8d18-bf5bee848c52n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/915ff447-502e-45c2-8d18-bf5bee848c52n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM2W4oqC4ZcC29YbeJ6uPP%2BV-q2B6Y%2Bg%3DCJver5ygArw8Q%40mail.gmail.com.
