This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 676357 - (CVE-2011-0696) CVE-2011-0696 django Flaw in CSRF handling
CVE-2011-0696 django Flaw in CSRF handling
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
public=20110209,reported=20110209,sou...
: Security
: 676459 (view as bug list)
Depends On: 676360
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-09 11:06 EST by Josh Bressers
Modified: 2016-03-04 07:52 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-17 07:21:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Josh Bressers 2011-02-09 11:06:19 EST
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 11:09:17 EST
Created Django tracking bugs for this issue

Affects: fedora-all [bug 676360]
Comment 2 Steve Milner 2011-02-15 14:33:20 EST
*** Bug 676459 has been marked as a duplicate of this bug. ***
Comment 3 Michel Alexandre Salim 2011-03-17 07:21:55 EDT
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.