James Bennett of the Django Project reports:

Security releases issued

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.

References:

https://www.djangoproject.com/weblog/2012/jul/30/security-releases-issued/