In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.4.20, 1.6.11, 1.7.7 and 1.8c1. These releases are now available on PyPI and our download page. These releases address several security issues detailed below. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated.
Django 1.8 is now at release candidate stage. This marks the string freeze and the call for translators to submit translations. Provided no major bugs are discovered that can't be solved in the next two weeks, 1.8 final will be issued on or around April 1. Any delays will be communicated on the django-developers mailing list thread.
Denial-of-service possibility with strip_tags()
Last year django.utils.html.strip_tags was changed to work
iteratively. The problem is that the size of the input it's processing can
increase on each iteration which results in an infinite loop in
strip_tags(). This issue only affects versions of Python that haven't
received a bugfix in HTMLParser; namely
Python < 2.7.7 and 3.3.5. Some operating system vendors have also backported
the fix for the Python bug into their packages of earlier versions.
To remedy this issue, strip_tags() will now return the original input if
it detects the length of the string it's processing increases. Remember that
absolutely NO guarantee is provided about the results of strip_tags() being
HTML safe. So NEVER mark safe the result of a strip_tags() call without
escaping it first, for example with django.utils.html.escape.
Thanks Andrey Babak for reporting the issue.
This issue has been assigned the identifier CVE-2015-2316.
Mitigated possible XSS attack via user-supplied redirect URLs
Django relies on user input in some cases (e.g.
django.contrib.auth.views.login and i18n)
to redirect the user to an "on success" URL. The security checks for these
redirects (namely django.utils.http.is_safe_url()) accepted URLs with
leading control characters and so considered URLs like \x08javascript:...
safe. This issue doesn't affect Django currently, since we only put this URL
into the Location response header and browsers seem to ignore JavaScript
there. Browsers we tested also treat URLs prefixed with control characters such
as %08//example.com as relative paths so redirection to an unsafe target
isn't a problem either.
However, if a developer relies on is_safe_url() to
provide safe redirect targets and puts such a URL into a link, they could
suffer from an XSS attack as some browsers such as Google Chrome ignore control
characters at the start of a URL in an anchor href.
Thanks Daniel Chatfield for reporting the issue.
This issue has been assigned the identifier CVE-2015-2317.
Affected versions
Django master development branch
Django 1.8 (currently at release candidate status)
Django 1.7
Django 1.6
Django 1.4 (is_safe_url() issue only)
Per our supported versions policy, Django 1.5 is no longer receiving security updates.
Resolution
Patches have been applied to Django's master development branch and to the 1.4, 1.6, 1.7, and 1.8
release branches, which resolve the issues described above. The patches may be obtained
directly from the following changesets:
On the development master branch:
master strip_tags patch
master is_safe_url patch
On the 1.8 release branch:
1.8 strip_tags patch
1.8 is_safe_url patch
On the 1.7 release branch:
1.7 strip_tags patch
1.7 is_safe_url patch
On the 1.6 release branch:
1.6 strip_tags patch
1.6 is_safe_url patch
On the 1.4 release branch:
1.4 is_safe_url patch
The following new releases have been issued:
Django 1.8c1 (download Django 1.8c1 | 1.8c1 checksums)
Django 1.7.7 (download Django 1.7.7 | 1.7.7 checksums)
Django 1.6.11 (download Django 1.6.11 | 1.6.11 checksums)
Django 1.4.20 (download Django 1.4.20 | 1.4.20 checksums)
The PGP key ID used for these releases is Tim Graham: 1E8ABDC773EDE252.
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.