Fixed #15258 - Ajax CSRF protection doesn't apply to PUT or DELETE requests

Thanks to brodie for the report, and further input from tow21

This is a potentially backwards incompatible change - if you were doing
PUT/DELETE requests and relying on the lack of protection, you will need to
update your code, as noted in the releaste notes.

git-svn-id: http://code.djangoproject.com/svn/django/trunk@16201 bcc190cf-cafb-0310-a4f2-bffc1f526a37

2 files changed, 25 insertions, 12 deletions

diff --git a/docs/ref/contrib/csrf.txt b/docs/ref/contrib/csrf.txt
index b42dc26fbd..9441393c81 100644
--- a/docs/ref/contrib/csrf.txt
+++ b/docs/ref/contrib/csrf.txt
@@ -13,11 +13,13 @@ who visits the malicious site in their browser.  A related type of attack,
 'login CSRF', where an attacking site tricks a user's browser into logging into
 a site with someone else's credentials, is also covered.
 
-The first defense against CSRF attacks is to ensure that GET requests are
-side-effect free.  POST requests can then be protected by following the steps
-below.
+The first defense against CSRF attacks is to ensure that GET requests (and other
+'safe' methods, as defined by `9.1.1 Safe Methods, HTTP 1.1, RFC 2616`_) are
+side-effect free.  Requests via 'unsafe' methods, such as POST, PUT and DELETE,
+can then be protected by following the steps below.
 
 .. _Cross Site Request Forgeries: http://www.squarefree.com/securitytips/web-developers.html#CSRF
+.. _9.1.1 Safe Methods, HTTP 1.1, RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
 
 How to use it
 =============
@@ -198,9 +200,9 @@ The CSRF protection is based on the following things:
 
    This part is done by the template tag.
 
-3. For all incoming POST requests, a CSRF cookie must be present, and the
-   'csrfmiddlewaretoken' field must be present and correct. If it isn't, the
-   user will get a 403 error.
+3. For all incoming requests that are not using HTTP GET, HEAD, OPTIONS or
+   TRACE, a CSRF cookie must be present, and the 'csrfmiddlewaretoken' field
+   must be present and correct. If it isn't, the user will get a 403 error.
 
    This check is done by ``CsrfViewMiddleware``.
 
@@ -215,12 +217,11 @@ The CSRF protection is based on the following things:
 This ensures that only forms that have originated from your Web site can be used
 to POST data back.
 
-It deliberately only targets HTTP POST requests (and the corresponding POST
-forms). GET requests ought never to have any potentially dangerous side effects
-(see `9.1.1 Safe Methods, HTTP 1.1, RFC 2616`_), and so a CSRF attack with a GET
-request ought to be harmless.
-
-.. _9.1.1 Safe Methods, HTTP 1.1, RFC 2616: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
+It deliberately ignores GET requests (and other requests that are defined as
+'safe' by RFC 2616). These requests ought never to have any potentially
+dangerous side effects , and so a CSRF attack with a GET request ought to be
+harmless. RFC 2616 defines POST, PUT and DELETE as 'unsafe', and all other
+methods are assumed to be unsafe, for maximum protection.
 
 Caching
 =======
diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt
index 1b8510f461..be95d2f02b 100644
--- a/docs/releases/1.4.txt
+++ b/docs/releases/1.4.txt
@@ -214,3 +214,15 @@ you should add the following lines in your settings file::
 
 Don't forget to escape characters that have a special meaning in a regular
 expression.
+
+CSRF protection extended to PUT and DELETE
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Previously, Django's :doc:`CSRF protection </ref/contrib/csrf/>` provided
+protection against only POST requests. Since use of PUT and DELETE methods in
+AJAX applications is becoming more common, we now protect all methods not
+defined as safe by RFC 2616 i.e. we exempt GET, HEAD, OPTIONS and TRACE, and
+enforce protection on everything.
+
+If you using PUT or DELETE methods in AJAX applications, please see the
+:ref:`instructions about using AJAX and CSRF <csrf-ajax>`.