Bug 844518 - (CVE-2012-3442) CVE-2012-3442 Django: 1.3.1 and 1.4.0 Cross-site scripting in authentication views
CVE-2012-3442 Django: 1.3.1 and 1.4.0 Cross-site scripting in authentication ...
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 844519 844520
  Show dependency treegraph
Reported: 2012-07-30 21:42 EDT by Kurt Seifried
Modified: 2016-04-26 11:52 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-09-12 15:14:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2012-07-30 21:42:32 EDT
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

    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.


Comment 1 Kurt Seifried 2012-07-30 21:43:52 EDT
Created Django tracking bugs for this issue

Affects: fedora-all [bug 844519]
Comment 2 Kurt Seifried 2012-07-30 21:44:50 EDT
Created Django tracking bugs for this issue

Affects: epel-all [bug 844520]
Comment 3 Fedora Update System 2012-08-10 18:26:54 EDT
Django-1.4.1-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 4 Fedora Update System 2012-08-10 18:33:44 EDT
Django-1.3.2-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Fedora Update System 2012-08-21 14:35:07 EDT
Django-1.3.2-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.