Changes between Initial Version and Version 14 of Ticket #24496


Ignore:
Timestamp:
Aug 31, 2015, 9:43:08 PM (9 years ago)
Author:
Joshua Kehn
Comment:

Based on the mailing list discussion here ​https://groups.google.com/forum/#!topic/django-developers/eQeaNzSlSbw I'm updating the ticket description and including a PR with tests and updated documentation that allows expanding the allowed HTTP Referer domains via a setting called CSRF_TRUSTED_ORIGINS.

PR is open: ​https://github.com/django/django/pull/5218

A patch has been added to this ticket as well.

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #24496

    • Property Triage Stage Unreviewed → Accepted
    • Property Cc django@… added
    • Property Owner changed from nobody to Joshua Kehn
    • Property Status new → assigned
    • Property Summary Check CSRF Referer against CSRF_COOKIE_DOMAIN → Check CSRF Referer against CSRF_TRUSTED_ORIGINS

  • Ticket #24496 – Description

    initial v14  
    11Right now, if you try to share a CSRF token across a subdomain without https, everything works great since the Referer header isn't validated.
    22
    3 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. The canonical source for where we think it should be from is `CSRF_COOKIE_DOMAIN`.
    4 
    5 If we set our `CSRF_COOKIE_DOMAIN` to `.example.com`, that means our CSRF validation should work for `www.example.com` and `foo.example.com`. Not just strictly the domain the request is coming from.
     3But 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`.
Back to Top