#24496: Check CSRF Referer against CSRF_TRUSTED_ORIGINS
------------------------------+------------------------------------
Reporter: mattrobenolt | Owner: joshkehn
Type: New feature | Status: assigned
Component: CSRF | Version: master
Severity: Normal | Resolution:
Keywords: csrf | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+------------------------------------
Comment (by carljm):
Replying to [comment:21 joshkehn]:
> Right, my question was with `CSRF_TRUSTED_ORIGINS` explicitly set
wouldn't someone reasonably assume that it's a filter on top of
`CSRF_COOKIE_DOMAIN`?
>
> Example: Set `CSRF_COOKIE_DOMAIN` to `.example.com` for convenience of
configuration so that the cookie is shared among any subdomain. Set
`CSRF_TRUSTED_ORIGINS` to only allow certain referers to pass the CSRF
checks.
>
> My suggestion would be to only use `CSRF_COOKIE_DOMAIN` if
`CSRF_TRUSTED_ORIGINS` is empty and make that a separate branch of logic.
It's a reasonable point, but I don't think so. Any host you are willing to
share the CSRF cookie with is implicitly trusted to make use of it.
Sharing the cookie is actually already a much deeper level of trust than
that provided by CSRF_TRUSTED_ORIGINS alone, because it allows that host
to get past both parts of the CSRF check, referrer and token.
CSRF_TRUSTED_ORIGINS is a technique for adding _additional_ hosts who can
bypass the referrer check, it's not a mechanism for restriction.
With your proposed behavior, it would be impossible to both have many
wildcarded subdomains AND an external CORS-using host. That would be
pretty frustrating.
Certainly the interaction of the two settings should be documented
clearly.
> Carl, I'm not sure if there's an easy way to split out into a new
ticket. Do you have one? If not, I can manually do it a bit later today.
No, there's no secret technique for that. Shouldn't be too hard; I
wouldn't try to copy all the comments or anything. Just open a new ticket
and say "some previous discussion in #24496", and re-title your pull
request so it gets linked up with the new ticket.
--
Ticket URL: <https://code.djangoproject.com/ticket/24496#comment:22>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/070.c221c2aaead6ce57870b0e514324130f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
