Django should assume port 443 for https in django.utils.http.is_same_domain()

[Ruslan Dautkhanov]

More complete explanation posted here - ​https://stackoverflow.com/questions/53658795/django-how-to-disable-referer-check

the issue is probably in Django code here: ​https://github.com/django/django/blob/22e8ab02863819093832de9f771bf40a62a6bd4a/django/middleware/csrf.py#L280

referer variable there is a urlparse object (see ​https://docs.python.org/3/library/urllib.parse.html ) which contains "netloc" property with a port.

Notice the error again - netlocs don't match because one has a port (443) and another doesn't have it (443 port is default for https):

Referer checking failed -

​https://hue-dev.discover.abc.com/hue/accounts/login/?next=/
does not match
​https://hue-dev.discover.abc.com:443/.

so I guess it should be some sort of Referer field transformation made in nginx config to cut out 443 port explicitly (or add it).

Referer check is failing because django.utils.http.is_same_domain() takes into account port
(in referer.netloc ).

Django should assume that port 443 is default for httpS, and not fail Referer check in this case.

[Ruslan Dautkhanov]

Related to #26037.

[Carlton Gibson]

As per the Stack Overflow question linked, the issue here is a wrong Nginx configuration.

proxy_set_header X-Forwarded-Host $host:$server_port;

You just want to be using $host, and drop the $server_port bit.

[Ruslan Dautkhanov]

Hi Carlton,

If Django assume that port 443 is default for httpS, then it'll not fail Referer check in this case.

​https://web.site.com/
and
​https://web.site.com:443/
are the same thing, but not for Django referer check.

What we did in nginx is a workaround.

Real problem is on Django side.

Thank you!
Ruslan

[Carlton Gibson]

Neither the Host nor the X-Forwarded-Host include the scheme right? As such it's just not right to say that web.site.com and web.site.com:443 are the same. The latter includes more information. (Yes, if we also lookup the scheme we might infer the 443 but we're making assumptions in doing so.)

The suggested fix on Stack Overflow seems right to me. (If you must send the port, beyond correcting the Nginx config, you can already adjust ALLOWED_HOSTS and/or CSRF_TRUSTED_ORIGINS here.)

[Ruslan Dautkhanov]

As I mentioned on SO, we use Django as part of Cloudera Hue product ​https://github.com/cloudera/hue
and there is no way to inject Django configs like ALLOWED_HOSTS and/or CSRF_TRUSTED_ORIGINS there.
Anyway, this would be a workaround for this problem, not a solution.

infer the 443 but we're making assumptions in doing so

Port 443 is not an assumption, but part of Internet Standard RFC-2818
​https://tools.ietf.org/html/rfc2818

the default port is 443

All browsers for example, when you type in ​https://abc.com "assume" same thing unless port is given,
and they "assume" port 80 when you specify http:// - because it's part of Internet Standard.

Neither the Host nor the X-Forwarded-Host include the scheme right?
As such it's just not right to say that web.site.com and web.site.com:443 are the same.

Not quite right. Django has X-Forwarded-Proto header and it knows that it's https and not http.

That's my last attempt to reopen this ticket. Thanks for the feedback, but I believe this
is a real problem in Django.

Moreover, not sure why Django is making a big deal from Referer check?
It's not a real security as Referer header can be easily spoofed
​https://security.stackexchange.com/questions/66165/does-referrer-header-checking-offer-any-real-world-security-improvement
I wish there would be a way to disable referer check altogether.

Thanks again.

[Carlton Gibson]

Please TicketClosingReasons/DontReopenTickets.

I see three options here:

1. Correct the Nginx config. This seems the obvious answer, the one on the Stack Overflow thread, and presumably you have no problem with it, since you think web.site.com and web.site.com:443 are equivalent, so there's no harm dropping the $server_port bit.
2. Add web.site.com:443 to CSRF_TRUSTED_ORIGINS (as others have done here).
3. Add logic examining the environment to infer the 443 port.

I'm sure we could get 3 roughly right with some effort. But I'm equally sure that it would turn out to be wrong for someone's setup. Then we'd have to add edge-case handling and opt-outs and all the rest of it.

In my view such things are simply not worth the effort when options 1 and 2 are available. I suggest you take one of those.

I wish there would be a way to disable referer check altogether.

You could always subclass the CSRF middleware. I wouldn't do that. (I'd go with option 1.)