December archive

Security releases issued

December 10, 2012

Today the Django team is issuing multiple releases -- Django 1.3.5, Django 1.4.3, and Django 1.5 beta 2 -- as part of our security process.

All users are encouraged to upgrade Django immediately.

Please be aware that this security release is slightly different from previous ones. Both issues addressed here have been dealt with in prior security updates to Django. In one case, we have received ongoing reports of problems, and in the other we've chosen to take further steps to tighten up Django's code in response to independent discovery of potential problems from multiple sources.

Host header poisoning

Several earlier Django security releases focused on the issue of poisoning the HTTP Host header, causing Django to generate URLs pointing to arbitrary, potentially-malicious domains.

In response to further input received and reports of continuing issues following the previous release, we're taking additional steps to tighten Host header validation. Rather than attempt to accommodate all features HTTP supports here, Django's Host header validation attempts to support a smaller, but far more common, subset:

  • Hostnames must consist of characters [A-Za-z0-9] plus hyphen ('-') or dot ('.').
  • IP addresses -- both IPv4 and IPv6 -- are permitted.
  • Port, if specified, is numeric.

Any deviation from this will now be rejected, raising the exception django.core.exceptions.SuspiciousOperation.

Redirect poisoning

Also following up on a previous issue: in July of this year, we made changes to Django's HTTP redirect classes, performing additional validation of the scheme of the URL to redirect to (since, both within Django's own supplied applications and many third-party applications, accepting a user-supplied redirect target is a common pattern).

Since then, two independent audits of the code turned up further potential problems. So, similar to the Host-header issue, we are taking steps to provide tighter validation in response to reported problems (primarily with third-party applications, but to a certain extent also within Django itself). This comes in two parts:

  1. A new utility function, django.utils.http.is_safe_url, is added; this function takes a URL and a hostname, and checks that the URL is either relative, or if absolute matches the supplied hostname. This function is intended for use whenever user-supplied redirect targets are accepted, to ensure that such redirects cannot lead to arbitrary third-party sites.
  2. All of Django's own built-in views -- primarily in the authentication system -- which allow user-supplied redirect targets now use is_safe_url to validate the supplied URL.

Affected versions

The issues resulting in this security release are present in the following versions of Django:

  • Django development master branch (officially, 1.6-pre-alpha at this time).
  • Django 1.5 prerelease branch (source of the 1.5 alpha and beta releases).
  • Django 1.4.
  • Django 1.3.


Patches have been applied to Django's master development branch, and to the 1.5, 1.4 and 1.3 release branches, which resolve the issues described above. The patches may be obtained directly from the following changesets:

The following new releases have been issed:

As Django's development branch is currently in a pre-alpha state, and the 1.5 branch is in a beta state, users are strongly advised not to be running production deployments from them; if you are currently doing so, however, you are urged to upgrade imediately to the latest HEAD of the appropriate branch, which contains the above patches.


The followup to the Host header issue came from the reporter of the previous issue, James Kettle. The potential problems with the redirect code were spotted independently by user "Gunnar" in Trac, and by committer Florian Apolloner.

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers list. Please see our security policies for further information.

Karen Tracey joins the DSF board

December 4, 2012

In late October, the DSF announced the resignation of Jacob Kaplan-Moss from the Django Software Foundation board.

The DSF membership nominated a group of potential candidates to replace fill Jacob's seat, and then voted on those nominations. These votes revealed a clearly preferred candidate, and late last week, the board of the Django Software Foundation (DSF) met and voted unanimously to confirm Karen Tracey to fill Jacob's seat on the DSF board.

Karen has been an active member of the Django community for many years. She has been a regular contributor to the Django Users and Django Developers mailing lists, and quite literally wrote the book on Django testing. She has been a member of the core team for over 4 years, and was one of the first developer members appointed to the DSF. She's also an avid author of crosswords and rescuer of cats.

The DSF would again like to thank Jacob for his many years of service to the DSF, including acting as the DSF president for the first 2 years of the DSF's existence. We look forward to seeing the contributions that Karen can bring to the DSF board.

DjangoCon Europe 2013 Call For Papers

December 4, 2012

DjangoCon Europe 2013 organizers are pleased to invite all members of the Django community to submit their talk proposals for the conference. We’re looking for Django and Python enthusiasts, pioneers, adventurers and anyone else who would like to share their Django achievements and experiments with the rest of the community.

For more information, please read the announcement on the DjangoCon Europe website.