The django.http.HttpRequest.get_host function in Django 1.3.x before 1.3.4 and 1.4.x before 1.4.2 allows remote attackers to generate and display arbitrary URLs via crafted username and password Host header values.

python-django was updated to 1.4.5 to fix various security issues and bugs.

Update to 1.4.5 :

  - Security release.

  - Fix bnc#807175 / bnc#787521 / CVE-2012-4520 /     CVE-2013-0305 / CVE-2013-0306 and CVE-2013-1665.

  - Update to 1.4.3 :

  - Security release :

  - Host header poisoning

  - Redirect poisoning

  - Please check release notes for details:
    https://www.djangoproject.com/weblog/2012/dec/10/securit     y

  - Add a symlink from /usr/bin/django-admin.py to     /usr/bin/django-admin

  - Update to 1.4.2 :

  - Security release :

  - Host header poisoning

  - Please check release notes for details:
    https://www.djangoproject.com/weblog/2012/oct/17/securit     y

  - Update to 1.4.1 :

  - Security release :

  - Cross-site scripting in authentication views

  - Denial-of-service in image validation

  - Denial-of-service via get_image_dimensions()

  - Please check release notes for details:
    https://www.djangoproject.com/weblog/2012/jul/30/securit     y-releases-issued

  - Add patch to support CSRF_COOKIE_HTTPONLY config

James Kettle discovered that Django did not properly filter the Host HTTP header when processing certain requests. An attacker could exploit this to generate and display arbitrary URLs to users. Although this issue had been previously addressed in USN-1632-1, this update adds additional hardening measures to host header validation. This update also adds a new ALLOWED_HOSTS setting that can be set to a list of acceptable values for headers. (CVE-2012-4520)

Orange Tsai discovered that Django incorrectly performed permission checks when displaying the history view in the admin interface. An administrator could use this flaw to view the history of any object, regardless of intended permissions. (CVE-2013-0305)

It was discovered that Django incorrectly handled a large number of forms when generating formsets. An attacker could use this flaw to cause Django to consume memory, resulting in a denial of service.
(CVE-2013-0306)

It was discovered that Django incorrectly deserialized XML. An attacker could use this flaw to perform entity-expansion and external-entity/DTD attacks. This updated modified Django behaviour to no longer allow DTDs, perform entity expansion, or fetch external entities/DTDs. (CVE-2013-1664, CVE-2013-1665).

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

Several vulnerabilities have been discovered in Django, a high-level Python web development framework. The Common Vulnerabilities and Exposures project identifies the following problems :

  - CVE-2012-4520     James Kettle discovered that Django did not properly     filter the HTTP Host header when processing certain     requests. An attacker could exploit this to generate and     cause parts of Django, particularly the password-reset     mechanism, to display arbitrary URLs to users.

  - CVE-2013-0305     Orange Tsai discovered that the bundled administrative     interface of Django could expose supposedly-hidden     information via its history log.

  - CVE-2013-0306     Mozilla discovered that an attacker can abuse Django's     tracking of the number of forms in a formset to cause a     denial-of-service attack due to extreme memory     consumption.

  - CVE-2013-1665     Michael Koziarski discovered that Django's XML     deserialization is vulnerable to entity-expansion and     external-entity/DTD attacks.

Multiple host header poisoning flaws were found and fixed in Django.

The updated packages have been upgraded to the 1.3.5 version which is not affected by these issues.

James Kettle discovered Django did not properly filter the Host HTTP header when processing certain requests. An attacker could exploit this to generate and display arbitrary URLs to users.

Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

Security releases issued - Host header poisoning

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The Django Project reports :

- Host header poisoning

Some parts of Django -- independent of end-user-written applications
-- make use of full URLs, including domain name, which are generated from the HTTP Host header. Some attacks against this are beyond Django's ability to control, and require the web server to be properly configured; Django's documentation has for some time contained notes advising users on such configuration.

Django's own built-in parsing of the Host header is, however, still vulnerable, as was reported to us recently. The Host header parsing in Django 1.3 and Django 1.4 -- specifically, django.http.HttpRequest.get_host() -- was incorrectly handling username/password information in the header. Thus, for example, the following Host header would be accepted by Django when running on 'validsite.com' :

Host: validsite.com:random@evilsite.com

Using this, an attacker can cause parts of Django -- particularly the password-reset mechanism -- to generate and display arbitrary URLs to users.

To remedy this, the parsing in HttpRequest.get_host() is being modified; Host headers which contain potentially dangerous content (such as username/password pairs) now raise the exception django.core.exceptions.SuspiciousOperation.

- Documentation of HttpOnly cookie option

As of Django 1.4, session cookies are always sent with the HttpOnly flag, which provides some additional protection from cross-site scripting attacks by denying client-side scripts access to the session cookie.

Though not directly a security issue in Django, it has been reported that the Django 1.4 documentation incorrectly described this change, by claiming that this was now the default for all cookies set by the HttpResponse.set_cookie() method.

The Django documentation has been updated to reflect that this only applies to the session cookie. Users of Django are encouraged to review their use of set_cookie() to ensure that the HttpOnly flag is being set or unset appropriately.

ID	Name	Product	Family	Severity
75089	openSUSE Security Update : python-django (openSUSE-SU-2013:1203-1)	Nessus	SuSE Local Security Checks	medium
65096	Ubuntu 10.04 LTS / 11.10 / 12.04 LTS / 12.10 : python-django vulnerabilities (USN-1757-1)	Nessus	Ubuntu Local Security Checks	medium
64898	Debian DSA-2634-1 : python-django - several vulnerabilities	Nessus	Debian Local Security Checks	medium
63312	Mandriva Linux Security Advisory : python-django (MDVSA-2012:181)	Nessus	Mandriva Local Security Checks	medium
62937	Ubuntu 10.04 LTS / 11.10 / 12.04 LTS / 12.10 : python-django vulnerability (USN-1632-1)	Nessus	Ubuntu Local Security Checks	medium
62765	Fedora 17 : Django-1.4.2-1.fc17 (2012-16440)	Nessus	Fedora Local Security Checks	medium
62750	Fedora 16 : Django-1.3.4-1.fc16 (2012-16417)	Nessus	Fedora Local Security Checks	medium
62705	FreeBSD : django -- multiple vulnerabilities (5f326d75-1db9-11e2-bc8f-d0df9acfd7e5)	Nessus	FreeBSD Local Security Checks	medium
62673	Fedora 18 : python-django-1.4.2-1.fc18 (2012-16406)	Nessus	Fedora Local Security Checks	medium

Detections

Analytics

CVE-2012-4520

medium

Tenable Plugins

medium

medium

medium

medium

medium

medium

medium

medium

medium