Bug 676357 (CVE-2011-0696) - CVE-2011-0696 django Flaw in CSRF handling
Summary: CVE-2011-0696 django Flaw in CSRF handling
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2011-0696
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: public=20110209,reported=20110209,sou...
: 676459 (view as bug list)
Depends On: 676360
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-09 16:06 UTC by Josh Bressers
Modified: 2019-06-08 18:44 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-03-17 11:21:55 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 676459 None None None Never

Internal Links: 676459

Description Josh Bressers 2011-02-09 16:06:19 UTC
http://www.djangoproject.com/weblog/2011/feb/08/security/

Django includes a CSRF-protection mechanism, which makes use of a token
inserted into outgoing forms. Middleware then checks for the token's
presence on form submission, and validates it.

Previously, however, our CSRF protection made an exception for AJAX
requests, on the following basis:

   1. Many AJAX toolkits add an X-Requested-With header when using
XMLHttpRequest.
   2. Browsers have strict same-origin policies regarding XMLHttpRequest.
   3. In the context of a browser, the only way that a custom header of
this nature can be added is with XMLHttpRequest.

Therefore, for ease of use, we did not apply CSRF checks to requests that
appeared to be AJAX on the basis of the X-Requested-With header. The Ruby
on Rails web framework had a similar exemption.

Recently, engineers at Google made members of the Ruby on Rails development
team aware of a combination of browser plugins and redirects which can
allow an attacker to provide custom HTTP headers on a request to any
website. This can allow a forged request to appear to be an AJAX request,
thereby defeating CSRF protection which trusts the same-origin nature of
AJAX requests.

Michael Koziarski of the Rails team brought this to our attention, and we
were able to produce a proof-of-concept demonstrating the same
vulnerability in Django's CSRF handling.

To remedy this, Django will now apply full CSRF validation to all requests,
regardless of apparent AJAX origin. This is technically
backwards-incompatible, but the security risks have been judged to outweigh
the compatibility concerns in this case.

Additionally, Django will now accept the CSRF token in the custom HTTP
header X-CSRFTOKEN, as well as in the form submission itself, for ease of
use with popular JavaScript toolkits which allow insertion of custom
headers into all AJAX requests.

Comment 1 Josh Bressers 2011-02-09 16:09:17 UTC
Created Django tracking bugs for this issue

Affects: fedora-all [bug 676360]

Comment 2 Steve Milner 2011-02-15 19:33:20 UTC
*** Bug 676459 has been marked as a duplicate of this bug. ***

Comment 3 Michel Alexandre Salim 2011-03-17 11:21:55 UTC
All our branches now have either 1.2.5 or 1.1.4 as stable releases -- it appears that they were pushed without tagging the affected bugs.


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