I din't yet understand the risk from the 'Host' header issue. In order to modify this header for a user's traffic, wouldn't an attacker already be in control of the user's browser or (unsecured) network path to the server? And thus, would have even easier ways to display arbitrary malicious URLs/content?
Or is the mention of password resets an indicator that an attacker, in their own separate connection, can contaminate an email sent to other users with bad URLs? (If so, detecting suspicious Host values would seem to leave a risk that legal-looking but wrong Host values are still trusted by the email mechanism.)
Yup, that's basically it. It essentially makes phishing Django sites easier. The vulnerability could allow an attacker to send a legit email -- sent by the real site itself -- with a link that sends a user to a malicious site instead.
The fix as described seems to just check the Host header for suspiciously-formatted information. Is that also enough to prevent other wrong (but well-formatted) Host values from being used?
It seems to me that the deeper risk is composing emails based on a passed Host value, rather than any sort of canonical name the site has for itself. Does the warning about avoiding domain-wildcard setups mean this is still a risk, even after the latest fix?
> The fix as described seems to just check the Host header for suspiciously-formatted information. Is that also enough to prevent other wrong (but well-formatted) Host values from being used?
The note about "beyond Django's ability to control" seems hand-wavey to me. Avoiding the use of the Host header to construct URLs -- not necessarily as a quick fix, but as a long-term better-practices goal -- would put safety against such attacks completely under Django's control, and provide a bit more defense-in-depth.
My estimation of what would be most safe/robust would be for a deployment to know its own canonical hostname/base-URL, and use that trusted value in construction of emailed URLs.
Perhaps this would be one of the explicit parameters that vary in dev-vs-production configurations. Maybe it's looked up from a key that's the local hostname. Perhaps, even, it's looked up based on the 'Host' header, but if the key is absent it's a failure. (Then, the available mappings are a sort of whitelist.)
The official Django recommendation essentially equates to, "be sure to enforce a whitelist on passed 'Host' values at the HTTP server". So it's leaving responsibility to the many alternate web server configurations Django devs might be using... while it could be solved definitively with a slightly different practice inside Django itself.
It's a tough line to draw. Requiring users to whitelist every domain that might be used to access the app is a PITA, and makes the lives of new developers more annoying. (It also makes multi-tennancy by domain name, e.g. customer.example.com, a bit more difficult.)
On the other hand, you're completely right that the "you gotta get your upstream server configured correctly" advice is handwavy at best.
Seems like this is always the case, this tension between security and usability...
However, my idea is just what's already outlined above: avoid using 'Host', except (perhaps) as a key.
Declaring one or more approved hostnames for accessing an install isn't an onerous requirement (especially if you're assuming that when they're not doing it in Django, they must do it elsewhere to be safe).
Maybe some people (such as in multi-tenancy situations or to make dev/staging/production transitions easier) will choose to use 'Host' directly anyway, or some sort of wildcard for acceptable hostnames. That's fine, but then they'll be accepting the risk by conscious action, deviating from the safer default. That seems better than facing the risk by the inaction of overlooking this more-subtle webserver-configuration issue.
> However, my idea is just what's already outlined above: avoid using 'Host', except (perhaps) as a key.
Yes, this is a good idea in theory (it's an offshoot of the idea of avoiding using any data that's provided by the browser.) But in practice, it breaks down any time you need to generate a full URL into the site, i.e.:
* Callback URLs for schemes like OAuth, webhooks, IPN, etc.
* Transaction emails with links back to the site ("this week on example.com", "joe just mentioned you..." password resets, etc.)
* Links in Atom, RSS feeds, etc.
In each case, Django could require that hosts be hardcoded (perhaps in settings) instead of consulting requests, but that would make each of those things harder to use.
... I'm not really trying to have an argument here; I see your point completely and I think I probably agree, personally. But I am trying to point out that security and usability are often at odds, and that there isn't as much a "right answer" as there is a calibration between those two needs. Drawing the line in the right place is hard.
I can't totally disagree, but "enforcing a whitelist on the server" is not exactly a tall order. It's the default for many installs and IMHO is already a clear best practice for a production web server. Having your site available under hostnames you didn't intend to make public is generally not a good idea -- it runs the risk of Google picking the wrong one as canonical for one thing.
I agree, it's not a tall order on the webserver... but that means it's not a tall order in Django either... and Django devs may find it easier to do in Python/Django, compared to translating the Django admonitions into their various local server configurations.
Even if it's easy enough to do it elsewhere, if in practice it gets overlooked, and the risks of overlooking it are high, that would be a reason to make the lazy/common path the safest path.
If it's not a tall order on the webserver, it's not a tall order in Django either... but Django devs may find it easier to do in Python/Django, compared to translating the Django admonitions into their various local server configurations.
And even if it's easy enough to do it elsewhere, if in practice it gets overlooked and the costs of overlooking it are high, that would be a good reason to make the lazy/common path the safest path.
Or is the mention of password resets an indicator that an attacker, in their own separate connection, can contaminate an email sent to other users with bad URLs? (If so, detecting suspicious Host values would seem to leave a risk that legal-looking but wrong Host values are still trusted by the email mechanism.)