| Summary: | <dev-python/django-1.4.8 : XSS (CVE-2013-4249) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | python |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2013/08/14/1 | ||
| Whiteboard: | B4 [noglsa] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 484984 | ||
| Bug Blocks: | |||
CVE-2013-4249 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4249): Cross-site scripting (XSS) vulnerability in the AdminURLFieldWidget widget in contrib/admin/widgets.py in Django 1.5.x before 1.5.2 and 1.6.x before 1.6 beta 2 allows remote attackers to inject arbitrary web script or HTML via a URLField. |
From ${URL} : 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. @maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.