mailing list archives
Re: [CVE request] Django 1.4.6 security release
From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 14 Aug 2013 01:42:38 -0600
-----BEGIN PGP SIGNED MESSAGE-----
On 08/13/2013 11:31 PM, Moritz Muehlenhoff wrote:
Hi, this needs two CVE assignments:
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
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
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
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.
Please provide links to the vulnerable code/fixed code thanks.
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
-----END PGP SIGNATURE-----