#35458 closed Uncategorized (needsinfo)
Docs: clarify need for ALLOWED_HOSTS
Reported by: | Klaas van Schelven | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 5.0 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I understand why validation of the host header is important but I do not understand why this would be the responsibility of Django.
The docs for the settings mysteriously mention
which are possible even under many seemingly-safe web server configurations.
and the docs for the host header validation mention something similar:
Because even seemingly-secure web server configurations are susceptible to fake Host headers
and
Previous versions of this document recommended configuring your web server to ensure it validates incoming HTTP Host headers. While this is still recommended, in many common web servers a configuration that seems to validate the Host header may not in fact do so. For instance, even if Apache ..
However, these notes were added in 2013, when Apache still reigned supreme (moreover: a very different version, possibly with less sane defaults, of Apache). These days there are many more ways Django is deployed, not least of which cloud-based ones in which the passing of sane (actually checked) host headers is left up to some web-facing proxy / webserver in front of Django.
In 2024, is there still any reason to fear these "many" (undocumented) "seemingly-safe server configurations" or can I just use a sane proxy server and let that do the validation instead? Setting ALLOWED_HOSTS
to ["*"]
removes one more thing to think about while deploying.
In the context of a bug report (and not just a question): the documentation should clarify what the actual wrong configurations would be, it should be mentioned as "defense in depth" rather than a first line of defense or the whole idea of ALLOWED_HOSTS checking should be removed.
Previously asked on StackOverflow in slightly different words
Change History (3)
comment:1 by , 7 months ago
Component: | Uncategorized → Documentation |
---|---|
Resolution: | → needsinfo |
Status: | new → closed |
comment:2 by , 7 months ago
Those notes give slightly more context, but not too much more. i.e. "it has been reported to us that even with the recommended web server configurations there are still techniques available for tricking many common web servers into supplying the application with an incorrect and possibly malicious Host header." still leaves me to wonder what these techniques would be and how one could defend against them at the level of the webserver (Apache, Nginx) rather than Django.
I think you're suggesting that Django should recommend or imply having
ALLOWED_HOSTS
as["*"]
is safe.
This was indeed one of the options in my original post. However, having since tried my hand at properly configuring the front-facing part, I have come to the conclusion that defense in depth is indeed a good recommendation. Still, I think the wording of the docs could be more clear, but I have to admit I don't have a good alternative myself.
Closing this issue for now is good for me.
comment:3 by , 4 months ago
In addition: setting up a 'catch all' for SSL may be "somewhat hard", as e.g. documented here for nginx. This in turn may mean a site gets traffic that's not meant for it.
I believe the Django 1.4.4 release notes gives more context.
I think you're suggesting that Django should recommend or imply having
ALLOWED_HOSTS
as["*"]
is safe.You should discuss this on the Django forum and state why this should be updated/allowed. As this relates to security, we need very strong consensus and evidence that this is safe before we can make an update. The security team may also want to review such an update. During this discussion you might conclude to add some doc clarifications.
I am closing this request for now but if after a discussion you have a concrete proposal, please reopen the ticket for consideration.