

Django security releases issued - jacobian
https://www.djangoproject.com/weblog/2012/oct/17/security/

======
gojomo
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.)

~~~
nbpoole
I have no Django experience, but I can imagine how an attack like this works:

1\. Links are rendered via some function that takes into account the user's
current request (ie: to determine the proper host)

2\. The "reset your password by clicking this link" URL is generated using
that function.

3\. I am a malicious attacker and I submit a password reset request for your
account.

Thus, I can control the URL that is sent to you in an email.

~~~
jacobian
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.

[So please upgrade!]

~~~
gojomo
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?

~~~
jacobian
> 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?

No, it's not. As the release notes say, "Some attacks against this are beyond
Django's ability to control, and require the web server to be properly
configured"; see
[https://docs.djangoproject.com/en/1.4/topics/security/#host-...](https://docs.djangoproject.com/en/1.4/topics/security/#host-
headers-and-virtual-hosting) for details.

~~~
gojomo
Thanks for the clarification.

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.

~~~
eli
But most sites need to work from at least two hostnames (dev and production).
So would you need to set up a whitelist in advance?

~~~
gojomo
Not exactly, but sort of.

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.

~~~
eli
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.

~~~
gojomo
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.

------
djangouser
where can i sign up to receive emails when a new django release is published?

~~~
Tobu
<https://groups.google.com/group/django-announce/>

django-announce+subscribe@googlegroups.com

~~~
djangouser
subscribed. thank you

