79 lines
3.1 KiB
Plaintext
79 lines
3.1 KiB
Plaintext
==========================
|
|
Django 1.1.4 release notes
|
|
==========================
|
|
|
|
Welcome to Django 1.1.4!
|
|
|
|
This is the fourth "bugfix" release in the Django 1.1 series,
|
|
improving the stability and performance of the Django 1.1 codebase.
|
|
|
|
With one exception, Django 1.1.4 maintains backwards compatibility
|
|
with Django 1.1.3. It also contains a number of fixes and other
|
|
improvements. Django 1.1.4 is a recommended upgrade for any
|
|
development or deployment currently using or targeting Django 1.1.
|
|
|
|
For full details on the new features, backwards incompatibilities, and
|
|
deprecated features in the 1.1 branch, see the :doc:`/releases/1.1`.
|
|
|
|
Backwards incompatible changes
|
|
==============================
|
|
|
|
CSRF exception for AJAX requests
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
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.
|
|
|
|
Prior to Django 1.2.5, our CSRF protection made an exception for AJAX
|
|
requests, on the following basis:
|
|
|
|
* Many AJAX toolkits add an X-Requested-With header when using
|
|
XMLHttpRequest.
|
|
|
|
* Browsers have strict same-origin policies regarding
|
|
XMLHttpRequest.
|
|
|
|
* 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.
|
|
|
|
The following example using the jQuery JavaScript toolkit demonstrates
|
|
this; the call to jQuery's ajaxSetup will cause all AJAX requests to
|
|
send back the CSRF token in the custom X-CSRFTOKEN header::
|
|
|
|
$.ajaxSetup({
|
|
beforeSend: function(xhr, settings) {
|
|
if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
|
|
// Only send the token to relative URLs i.e. locally.
|
|
xhr.setRequestHeader("X-CSRFToken",
|
|
$("#csrfmiddlewaretoken").val());
|
|
}
|
|
}
|
|
});
|
|
|