#25334: Check CSRF Referer against CSRF_TRUSTED_ORIGINS
-----------------------------+--------------------------------------
     Reporter:  joshkehn     |                    Owner:  joshkehn
         Type:  New feature  |                   Status:  assigned
    Component:  CSRF         |                  Version:  master
     Severity:  Normal       |               Resolution:
     Keywords:  csrf         |             Triage Stage:  Unreviewed
    Has patch:  1            |      Needs documentation:  0
  Needs tests:  0            |  Patch needs improvement:  0
Easy pickings:  0            |                    UI/UX:  0
-----------------------------+--------------------------------------

Old description:

> See previous discussion in #24496
>
> Right now, if you try to share a CSRF token across a subdomain without
> https, everything works great since the Referer header isn't validated.
>
> But over https, we want to be a bit more strict and make sure that the
> Referer is from another secure site, and also that the Referer matches
> where we think it should be coming from. Django should validate that the
> Referer header matches one of the domains listed in
> `CSRF_TRUSTED_ORIGINS`, including the currently responding
> `ALLOWED_HOST`.

New description:

 Django's CSRF implementation (when used over HTTPS) validates that the
 Referer header matches the current host (i.e. that the request is coming
 from the same domain).

 There are cases where it is reasonable to allow non-same-origin CSRF-
 protected requests. Ticket #24996 (which also contains some discussion
 relevant to this ticket) has a pull request to allow any host that matches
 `CSRF_COOKIE_DOMAIN` past the Referer check; this takes care of the common
 subdomain cases.

 But there also cases where a totally separate domain may be allowed to
 make `POST` (etc) requests to an API via CORS, and CORS headers can be
 configured to allow XHR requests from that external domain to send cookies
 to the API (including the CSRF cookie). But at the moment such a technique
 falls afoul of the Referer checking, and the only way to bypass it is by
 monkeypatching the request headers (that's what https://github.com/ottoyiu
 /django-cors-headers does).

 This ticket proposes adding a `CSRF_TRUSTED_ORIGINS` setting, which can be
 set to a list of hosts that should be considered valid Referers for the
 purposes of CSRF checking.

--

Comment (by carljm):

 I'm updating the description here to try to more clearly describe the
 motivation for _this_ feature, why it is useful in addition to #24496.
 Please let me know if you think the new description is lacking.

--
Ticket URL: <https://code.djangoproject.com/ticket/25334#comment:2>
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/066.4398d45e24bc03319d3ddc8f60c1efa9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to