CVE-2010-3082: XSS
As of the 1.2 release, the core Django framework includes a system, enabled by default, for detecting and preventing cross-site request forgery (CSRF) attacks against Django-powered applications. Previous Django releases provided a different, optionally-enabled system for the same purpose.
The Django 1.2 CSRF protection system involves the generation of a random token, inserted as a hidden field in outgoing forms. The same value is also set in a cookie, and the cookie value and form value are compared on submission.
The provided template tag for inserting the CSRF token into forms -- {% csrftoken %} -- explicitly trusts the cookie value, and displays it as-is. Thus, an attacker who is able to tamper with the value of the CSRF cookie can cause arbitrary content to be inserted, unescaped, into the outgoing HTML of the form, enabling cross-site scripting (XSS) attacks.
This issue was first reported via a public ticket in Django's Trac instance; while being triaged it was then independently reported, with broader description, by Jeff Balogh of Mozilla.
http://www.djangoproject.com/weblog/2010/sep/08/security-release/
Other sources
Cross-site scripting (XSS) vulnerability in Django 1.2.x before 1.2.2 allows remote attackers to inject arbitrary web script or HTML via a csrfmiddlewaretoken (aka csrftoken) cookie.
— GitHub
Affected Software
Remediation
Patch Available
Event History
Frequently Asked Questions
What is the severity of CVE-2010-3082?
CVE-2010-3082 is classified as a moderate severity vulnerability affecting certain versions of Django.
How do I fix CVE-2010-3082?
To fix CVE-2010-3082, upgrade Django to version 1.2.2 or later.
Which versions of Django are affected by CVE-2010-3082?
CVE-2010-3082 affects Django versions 1.2.1 and 1.2.1-2.
What type of vulnerability is CVE-2010-3082?
CVE-2010-3082 is a cross-site request forgery (CSRF) vulnerability.
Is there a workaround for CVE-2010-3082?
There is no known effective workaround for CVE-2010-3082; upgrading is recommended.