First published: Wed Feb 09 2011(Updated: )
<a href="http://www.djangoproject.com/weblog/2011/feb/08/security/">http://www.djangoproject.com/weblog/2011/feb/08/security/</a> 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.
Affected Software | Affected Version | How to fix |
---|---|---|
Django |
Sign up to SecAlerts for real-time vulnerability data matched to your software, aggregated from hundreds of sources.
The severity of REDHAT-BUG-676357 is high due to the potential exploitation of the CSRF protection mechanism.
To fix REDHAT-BUG-676357, ensure you are using the latest version of Django that includes the patch for the CSRF vulnerability.
REDHAT-BUG-676357 addresses vulnerabilities related to Cross-Site Request Forgery (CSRF) in Django's protection mechanisms.
If you are using affected versions of Django without the necessary updates, your application may be vulnerable to REDHAT-BUG-676357.
REDHAT-BUG-676357 was reported in February 2011.