Re: [CVE request] Django 1.4.6 security release

[Kurt Seifried <kseifried () redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2013 11:31 PM, Moritz Muehlenhoff wrote:
> Hi, this needs two CVE assignments: 
> https://www.djangoproject.com/weblog/2013/aug/13/security-releases-issued/
> :
>
> Cheers, Moritz
>
>
> 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.

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)

iQIcBAEBAgAGBQJSCzTtAAoJEBYNRVNeJnmTms8QAMD1YlH09LBGN50Ya5ZDwY6q
YlUky1790kHc3E8r86mz2o7+UX++Y2yyrurxPOzaeDPbi0jmQi/lV+RZQUvj0ukk
+rfRciRdUm4dtQWPKHSZQOKvNA4carUI98O9BfsXacLLCHJRk8M2TWH7KodqI5sa
+5r+gOAgiRzA+ExuuSRCDWVZLU7lZdnyaAAWHj7G1YfIhvW1bILuSxBxYwl6g0FV
LuEfMnrpfCf2QKeoVHKrPtblGDRSQxxpKGbiyYNPhFYAhdxmLYWyxofiCnbh243k
sJu0oQwpI2LyHEH6UhOwMsOg+8H1OiDFoT7Rai0U/g7BlOpE9hMp5sBalHu4IFEb
kg9q43T7nZNYtoiYf6dJM/rnDpQdMJ3lQOpoG4KuGdfY9NoRhqUaxCf+8Y+mbiee
AgWiTM1BSt6hC69PgObYxYr4hbwizC2o4ULi0SDMXdwFHMLdWp0eAhPIPBkJorRH
9NZIGIWlgv4IwOaWYt4Vr4hxPiZJyx/Zlv3TqBEEvpnqflZp7N05T8JGCf6b61yg
q5wJQ9h6FXmbZ7y5aSs/i4zWjA4AToZz5T+l5Flke/37Y1S+FdQxegfIDk1Eg2Zf
va0YNfkmlrJzhEzjfrmrJWGmhh28tNrbz9ZKhr9SV50aGSh4ZbPAdFYyPHFbFIgD
xPfjENXhPYruMSdmzhpt
=y4tK
-----END PGP SIGNATURE-----