/docs/releases/1.1.4.txt
Plain Text | 68 lines | 51 code | 17 blank | 0 comment | 0 complexity | 09926718e21de2c5765cd837031f82e4 MD5 | raw file
Possible License(s): BSD-3-Clause
1========================== 2Django 1.1.4 release notes 3========================== 4 5Welcome to Django 1.1.4! 6 7This is the fourth "bugfix" release in the Django 1.1 series, 8improving the stability and performance of the Django 1.1 codebase. 9 10With one exception, Django 1.1.4 maintains backwards compatibility 11with Django 1.1.3. It also contains a number of fixes and other 12improvements. Django 1.1.4 is a recommended upgrade for any 13development or deployment currently using or targeting Django 1.1. 14 15For full details on the new features, backwards incompatibilities, and 16deprecated features in the 1.1 branch, see the :doc:`/releases/1.1`. 17 18Backwards incompatible changes 19============================== 20 21CSRF exception for AJAX requests 22~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 23 24Django includes a CSRF-protection mechanism, which makes use of a 25token inserted into outgoing forms. Middleware then checks for the 26token's presence on form submission, and validates it. 27 28Prior to Django 1.2.5, our CSRF protection made an exception for AJAX 29requests, on the following basis: 30 31 * Many AJAX toolkits add an X-Requested-With header when using 32 XMLHttpRequest. 33 34 * Browsers have strict same-origin policies regarding 35 XMLHttpRequest. 36 37 * In the context of a browser, the only way that a custom header 38 of this nature can be added is with XMLHttpRequest. 39 40Therefore, for ease of use, we did not apply CSRF checks to requests 41that appeared to be AJAX on the basis of the X-Requested-With header. 42The Ruby on Rails web framework had a similar exemption. 43 44Recently, engineers at Google made members of the Ruby on Rails 45development team aware of a combination of browser plugins and 46redirects which can allow an attacker to provide custom HTTP headers 47on a request to any website. This can allow a forged request to appear 48to be an AJAX request, thereby defeating CSRF protection which trusts 49the same-origin nature of AJAX requests. 50 51Michael Koziarski of the Rails team brought this to our attention, and 52we were able to produce a proof-of-concept demonstrating the same 53vulnerability in Django's CSRF handling. 54 55To remedy this, Django will now apply full CSRF validation to all 56requests, regardless of apparent AJAX origin. This is technically 57backwards-incompatible, but the security risks have been judged to 58outweigh the compatibility concerns in this case. 59 60Additionally, Django will now accept the CSRF token in the custom HTTP 61header X-CSRFTOKEN, as well as in the form submission itself, for ease 62of use with popular JavaScript toolkits which allow insertion of 63custom headers into all AJAX requests. 64 65Please see the :ref:`CSRF docs for example jQuery code <csrf-ajax>` 66that demonstrates this technique, ensuring that you are looking at the 67documentation for your version of Django, as the exact code necessary 68is different for some older versions of Django.