#31845 closed Bug (wontfix)
CSRF check fails when browsing with FQDN with trailing dot
Reported by: | ippei | Owned by: | nobody |
---|---|---|---|
Component: | CSRF | Version: | 2.2 |
Severity: | Normal | Keywords: | |
Cc: | Florian Apolloner | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
CSRF check seems to fail with "Referer checking failed" when user is browsing with FQDN with trailing dot.
At this line: https://github.com/django/django/blob/2.2.12/django/middleware/csrf.py#L280
while referer.netloc
has trailing dot, one of the good_hosts
that is supposed to match comes from request.get_host()
which strips the trailing dot.
is_same_domain
does not consider domain strings with and without trailing dots the same domain.
We neither set CSRF_USE_SESSIONS nor CSRF_COOKIE_DOMAIN in settings.
(Our system uses DRF, but the original error seems to come from the CsrfViewMiddleware implementation.)
For now, we set CSRF_TRUSTED_ORIGINS with our production domain with trailing dot to circumvent this issue.
Change History (4)
comment:1 by , 4 years ago
Description: | modified (diff) |
---|
comment:2 by , 4 years ago
Description: | modified (diff) |
---|
comment:3 by , 4 years ago
Cc: | added |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
comment:4 by , 4 years ago
thank you for your time.
probably my mistake debugging the issue and the cause may lay hidden somewhere else. (DRF, AWS, who knows...)
Browsers seem quite keen to strip that trailing . when trying to reproduce this?
I thought so too, but browsers seem to let users browsing with trailing dot as long as links and redirects stay within the site. However, it seems many web sites redirect requests with trailing dot to corresponding url without.
Hi. Thanks for the report. Interesting one.
I'm going to close as
wontfix
since I think this is expected behaviour.request.get_host()
doesn't strip anything — it ultimately just uses the information given in the WSGI environment, andis_same_domain()
shouldn't returnTrue
when the trailing slash is added (it's as you say, fully-qualified at that point...)I'll cc Florian, who knows more about these things and may be able to comment more authoritatively.
I'm struggling to see how this comes up. Browsers seem quite keen to strip that trailing
.
when trying to reproduce this?