August archive

DjangoCon US 2013 travel grants awarded

August 16, 2013

The financial assistance for DjangoCon US 2013 that the Django Software Foundation announced on July 22 has now been awarded. We owe our thanks to the DSF grants committee, chaired by Lynn Root, who undertook the work of processing the applications and notifying the applicants of the results.

We are happy to say that thanks to The Open Bastion's donation of $10,000 in free registrations, and with the addition of almost $4,000 of DSF funding towards travel and accommodation, 13 people will be going to Chicago who otherwise would not have been able to make the trip. Many thanks to the individual and corporate donors that made a financial contribution to the DSF that made these grants possible.

We look forward to seeing these grant recipients, and the rest of the Django community, in Chicago in September.

We also hope that we can continue to grow the funding for financial assistance and keep future DjangoCon events as affordable as possible.

Security releases issued

August 13, 2013

Today the Django team is issuing multiple releases -- Django 1.4.6, Django 1.5.2, and Django 1.6 beta 2 -- as part of our security process. These releases are now available on PyPI and our download page

These releases address two cross-site scripting (XSS) vulnerabilities: one in a widget used by Django's admin interface, and one in a utility function used to validate redirects often used after login or logout.

While these issues present limited risk and may not affect all Django users, we encourage all users to evaluate their own risk and upgrade when possible.

For more details, read on.

Issue: Cross-site scripting (XSS) in admin interface

The Django administrative application, django.contrib.admin, provides functionality for CRUD (Creation, Retrieval, Updating and Deleting) operations by trusted users, including facilities for both automatic and customized data-manipulation interfaces.

When displaying the value of a URLField -- a model field type for storing URLs -- this interface treated the values of such fields as safe, thus failing to properly accommodate the potential for dangerous values. A proof-of-concept application has been provided to the Django project, showing how this can be exploited to perform XSS in the administrative interface.

In a normal Django deployment, this will only affect the administrative interface, as the incorrect handling occurs only in form-widget code in django.contrib.admin. It is, however, possible that other applications may be affected, if those applications make use of form widgets provided by the admin interface.

To remedy this issue, the widget in question -- django.contrib.admin.widgets.AdminURLFieldWidget -- has been corrected to treat its value the same as any other potentially-user-supplied value; in other words, it will be treated as unsafe, and subject to Django's (enabled by default) output escaping.

Thanks to Ɓukasz Langa for reporting this issue to us.

Issue: Possible XSS via is_safe_url

A common pattern in Django applications is for a view to accept, via querystring parameter, a URL to redirect to upon successful completion of the view's processing. This pattern is used in code bundled with Django itself; for example, the login view in django.contrib.auth.views, which accepts such a parameter to determine where to send a user following successful login.

A utility function -- django.utils.http.is_safe_url() -- is provided and used to validate that this URL is on the current host (either via fully-qualified or relative URL), so as to avoid potentially dangerous redirects from maliciously-constructed querystrings.

The is_safe_url() function works as intended for HTTP and HTTPS URLs, but due to the manner in which it parses the URL, will permit redirects to other schemes, such as javascript:. While the Django project is unaware of any demonstrated ability to perform cross-site scripting attacks via this mechanism, the potential for such is sufficient to trigger a security response.

To remedy this issue, the is_safe_url() function has been modified to properly recognize and reject URLs which specify a scheme other than HTTP or HTTPS.

Thanks to Nick Bruun for reporting this issue to us.

Affected versions

The URLField XSS issue affects the following versions of Django:

  • Django 1.5
  • Django 1.6 (currently at beta status)
  • Django master development branch

The is_safe_url() issue affects the following versions of Django:

  • Django 1.4
  • Django 1.5
  • Django 1.6 (currently at beta status)
  • Django master development branch


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

On the development master branch:

On the Django 1.6 release branch:

On the Django 1.5 release branch:

On the Django 1.4 release branch:

The following new releases have been issued:

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.

Security advisory: BREACH and Django

August 6, 2013

At last week's Black Hat conference, researchers announced the BREACH attack, a new attack on web apps that can recover data even when secured with SSL connections. The BREACH paper (PDF) contains full details (and is a good and fairly easy read).

Given what we know so far, we believe that BREACH may be used to compromise Django's CSRF protection. Thus, we're issuing this advisory so that our users can defend themselves.

BREACH takes advantage of vulnerabilities when serving compressed data over SSL/TLS. Thus, to protect yourself from BREACH, you should disable compression of web responses. Depending on how your application is deployed, this could take a couple forms:

  1. Disabling Django's GZip middleware.
  2. Disabling GZip compression in your web server's config. For example, if you're using Apache you'd want to disable mod_deflate; in nginx you'd disable the gzip module.

Additionally, you should make sure you disable TLS compression by adjusting your server's SSL ciphers.

We plan to take steps to address BREACH in Django itself, but in the meantime we recommend that all users of Django understand this vulnerability and take action if appropriate.