October 17, 2012
\nThis is the fourth release in the Django 1.3 series.
\nSome parts of Django – independent of end-user-written applications – make\nuse of full URLs, including domain name, which are generated from the HTTP Host\nheader. Some attacks against this are beyond Django’s ability to control, and\nrequire the web server to be properly configured; Django’s documentation has\nfor some time contained notes advising users on such configuration.
\nDjango’s own built-in parsing of the Host header is, however, still vulnerable,\nas was reported to us recently. The Host header parsing in Django 1.3.3 and\nDjango 1.4.1 – specifically, django.http.HttpRequest.get_host() – was\nincorrectly handling username/password information in the header. Thus, for\nexample, the following Host header would be accepted by Django when running on\nvalidsite.com:
Host: validsite.com:random@evilsite.com\nUsing this, an attacker can cause parts of Django – particularly the\npassword-reset mechanism – to generate and display arbitrary URLs to users.
\nTo remedy this, the parsing in HttpRequest.get_host() is being modified;\nHost headers which contain potentially dangerous content (such as\nusername/password pairs) now raise the exception\ndjango.core.exceptions.SuspiciousOperation.
Details of this issue were initially posted online as a security advisory.
\n