July archive

Apply for financial assistance to DjangoCon US

July 30, 2012

If you’d like to go to DjangoCon 2012 in Washington, D.C. — or know a talented developer who does — but cannot attend due to financial hardship, please apply for financial aid through DjangoCon. And, if you’re a PyLady (as opposed to a PyLaddie), please indicate that you would like to be considered for a PyLadies grant on that form. Your application will be confidential unless you prefer otherwise.

This year’s conference is from Sept. 3 to Sept. 9. The deadline for the grant submission is Friday, August 3rd. We apologize for the short notice, but we know that people need time to make travel plans/request days off from work, etc. You will hear from us by the end of the week after applications are submitted.

If you know of a talented, deserving developer (of any gender) who might benefit greatly from attending DjangoCon, please encourage them to apply. Many thanks to Lynn Root, PyLadies, the DjangoCon organizers and the Python Software Foundation for helping manage this program.

Security releases issued

July 30, 2012

Today the Django team is issuing multiple releases -- Django 1.3.2 and Django 1.4.1 -- to remedy security issues reported to us.

All users are encouraged to upgrade Django immediately.

Cross-site scripting in authentication views

The login() and logout() views provided in Django's authentication framework make use of the common "POST-redirect-GET" pattern; a configurable querystring parameter can be used to specify the location to redirect to on successful submission. Currently, those views perform basic validation to ensure that the redirect location does not specify a different domain.

However, this validation does not check the scheme of the target URL; armed with this knowledge, an attacker can craft, for example, a data: scheme URL which will execute JavaScript.

Some browsers are known to currently provide protection against this issue: Google Chrome in particular explicitly disallows redirects to data: scheme URLs. However, several other major browsers do permit such redirects.

After careful consideration of this issue, we have decided that the safest course of action involves a slight break to backwards compatibility. Although temporary mitigation could be achieved through more stringent validation in the relevant views, the root issue lies in Django's HTTP response classes, which currently do not perform any validation of redirect targets. The fact that some major browsers already disallow certain URL schemes in redirects indicates that the impact of this change is likely to be minimal.

As such, the following change is being made despite breaking API compatibility:

  • django.http.HttpResponseRedirect and django.http.HttpResponsePermanentRedirect now subclass a common base class, django.http.HttpResponseRedirectBase.
  • That base class defines an explicit whitelist of allowed URL schemes. Attempts to instantiate a redirect with a URL of a scheme not in the whitelist will raise the exception django.core.exceptions.SuspiciousOperation, which is already employed for similar purposes in other parts of Django's codebase (e.g., to warn of possible session tampering).

End-user code which issues redirects is unlikely to be affected unless it either explicitly requires redirecting to an unsupported scheme, or accepts the target URL from a user-supplied parameter.

In the former case, subclassing the appropriate redirect class (HttpResponseRedirect for status code 302, HttpResponsePermanentRedirect for status code 301) and overriding the allowed_schemes list will be sufficient. The default value of allowed_schemes is ['http', 'https', 'ftp'].

In the latter case, code which accepts user-supplied parameters can attempt to instantiate the redirect, catch the SuspiciousOperation exception, and fall back to an alternate location as needed.

At present, Django's authentication views will leave this exception uncaught. This means site administrators will receive error reports if/when that exception is raised. It is likely that future Django releases will begin catching this exception, after allowing some time for users of Django to observe behavior and judge their exposure to potential issues.

Denial-of-service in image validation

Django's form system includes field types for handling file uploads, including a field class -- django.forms.ImageField -- for uploading images, which can perform some validation of image formats.

Part of that validation involves detecting corrupted image files, using routines provided by the Python Imaging Library (PIL).

The check as it currently exists in Django is vulnerable, however, because it will read the entire image file, including decompressing compressed formats as needed. It is trivially possible to craft a reasonably-sized file which, when decompressed in this fashion, grows to enormous size, consuming available memory and offering the ability to perform a denial-of-service attack.

To mitigate this, image validation will now make use of PIL's Image.verify() method, which performs some validation checks but does not decompress or read the entire image file.

Denial-of-service via get_image_dimensions()

Django's image-handling facilities also include helper methods to determine the dimensions of an image. Currently, the process for this involves reading a 1024-byte chunk from the start of the file, and passing to PIL to determine the dimensions; if insufficient data is provided, further 1024-byte chunks are read until PIL is able to return a definite answer.

While this works well for image formats which store enough information in their headers to determine dimensions, it can result in large quantities of read/process cycles for formats which do not. In particular, larger TIFF images can require tens of thousands of such cycles, tying up or timing out worker processes/threads and consuming enough server resources to result in an effective denial-of-service.

To mitigate this, the algorithm for determining image dimensions is being changed; the initial attempt will still use a 1024-byte chunk, but the chunk size will be doubled on each successive read. Testing has demonstrated that this reduces time to process TIFF files by multiple orders of magnitude.

Affected versions

The issues described above are present in the following versions of Django:

  • Django development master branch
  • Django 1.4
  • Django 1.3


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

  • Development master branch: commit for the redirect issue, commit for the image-validation issue and commit for the image-dimensions issue.
  • Django 1.4: commit for the redirect issue, commit for the image-validation issue and commit for the image-dimensions issue.
  • Django 1.3: commit for the redirect issue, commit for the image-validation issue and commit for the image-dimensions issue.

The following new releases have been issued:

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


The issue with determining image dimensions was reported to us Jeroen Dekkers. The image-validation issue was reported as a regular bug by a user in Django's Trac. The redirect issue was reported by a source who has chosen to remain anonymous.

Known status of these issues

The Django team has been provided with information which indicates that knowledge of the redirect issue extends beyond the original reporter, and may either currently be or soon be exploited by persons in possession of that knowledge. And as noted above, the image-validation issue was originally reported to Django's public bug tracker.

As such, we again urge all users of affected versions of Django to upgrade immediately.

General notes regarding security

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.

If you are or represent a third-party distributor of Django and did not receive a notification email regarding this announcement from the Django release manager, please contact james@b-list.org.

New directors and members for the DSF

July 27, 2012

Earlier this month, we announced the resignation of Dan Cox from the Django Software Foundation board. Since then, the DSF membership has been nominating and discussing possible replacements.

These discussions led to a clearly preferred candidate; so earlier this week, the board of the Django Software Foundation (DSF) met and voted unanimously to confirm Alex Gaynor to fill Dan's seat on the DSF board.

Alex has been a member of the Django community for many years. He was a Google Summer of Code student in 2009 and 2010, and has been a member of the core team for almost 2 years. He was also one of the first developer members appointed to the DSF.

Following nominations from the DSF membership, the DSF board has also confirmed the first two Developer Members who aren't also committers -- Daniel Greenfeld and Jonas Obrist. Although they aren't members of the core team, Daniel and Jonas have both made significant contributions to the broader Django community through their efforts in organising conferences, and managing valuable Django-related projects.

Welcome to Alex, Daniel and Jonas!

SF Django Sprint #5: Tutorial improvement

July 26, 2012

Votizen will host its fifth regularly-occuring Django sprint in San Francisco Saturday, August 4th, from 10 a.m. to 6 p.m. This sprint focuses on improving the Django tutorial. Lunch will be provided, along with seating, Internet, whiteboards, and small-batch coffee. The sprint will be hosted at Votizen's office near the 4th and King Caltrain station.

Please sign up to attend through SF Django or PyLadies SF.

We hope to see you there!

Third regularly-scheduled San Francisco Sprint

July 5, 2012

Votizen will host its third regularly-occuring Django sprint in San Francisco this Saturday, July 7th, from 10 a.m. to 6 p.m. This third sprint targets tickets with patches that need a bit of polish to be ready to commit.

These sprints will be on the 1st and 3rd weekends of each month, generally on Saturdays. They'll be hosted at Votizen's office near the 4th and King Caltrain station.

Seating, Internet, and whiteboards will be provided, along with drinks and small-batch coffee.

Attendance is limited to 25 (for now: future events may be bigger), so please sign up to attend.

We hope to see you there!