CSRF + AJAX

Assuming this is a check for the X-Requested-By: XMLHttpRequest header, I'm all for it - it's a nice, secure way of allowing Ajax requests to avoid having to include a form token, which can be tricky to make available to the Ajax code otherwise.

It's using the request.is_ajax() function. This is documented here: http://www.djangoproject.com/documentation/request_response/#methods

Quote: """ Returns True if the request was made via an XMLHttpRequest, by checking the HTTP_X_REQUESTED_WITH header for the string 'XMLHttpRequest'. """

I'm currently trying to do the svn diff. First time I did it, so please don't shoot me if I did something wrong :)

** Edit ** I have attached the diff file, I hope it is as wanted...

Hi,

Actually, this is a problem that might bite the unwary: If you use the CSRF middleware, and do JSON posts, you will run into trouble right now.

Personally, I prefer to check the key in JSON request bodies as well (being a bit paranoid, hey I'm using the CSRF middleware :-/).

So the attached diff (csrf_check_ajax_requests_too.diff) checks for a HTTP_X_CSRFMIDDLEWARETOKEN in the HTTP header. You can easily add that header in most Ajax libraries, e.g. request.setHeader('X-CsrfMiddlewareToken', document.getElementById('csrfmiddlewaretoken').value); .

The only downside you have is that there might not be a key on a webpage because it has no <form method="post"> in the response. That seems to be the exception in my experience, and that can be worked around just as easy.

Get the CSRF token from HTTP headers when using Ajax requests

Uh, oops:

My patch should have checked the Content-Type of the request body, and assume that requests of the type application/x-www-form-urlencoded are still handled with the existing request.POST['csrfmiddlewaretoken'] .

More rationale:

Actually, this is a problem that might bite the unwary: If you use the CSRF middleware, and do JSON posts, you will run into trouble right now.

That goes for any POST request that isn't application/x-www-form-urlencoded. Which is why it would be welcome to make the request processing more robust, regardless of the design choice to check for the token or not.

Perhaps the best way to go is to make CSRF generate a key per-standard, and make it available. That way, at all points in the application, the string is usable and the ajax user could implement that into the "form" sent through.

I found a SecurityFocus? article[1] that mentions that Adobe Flash is capable of both cross-site requests and setting arbitrary HTTP headers. If this is true, then relying on the X-Requested-With header will allow hostile cross-site requests if a user visits a malicious site.

Is this concern accurate, or does Flash enforce the same cross-site rules as the XMLHttpRequest object?

[1] http://www.securityfocus.com/archive/1/441014

We had some issues with csrf and ajax when we used an flash uploader in combination with windows and firefox. in this special case, flash is sending the IE cookies instead of the Firefox cookies and therefore CSRF raises an error because no valid session is available. What we did, to get csrf working even with the flash YUI upload:

• we added the csrfmiddlewaretoken to the ajax post request
• we wrote a patch during the implementation of www.xipax.com for the middleware.py which checks if there is POST variable called session_id, if not, it falls back to the standard behaviour of the CSRF middleware

This file is attached to the ticket

patch which allows to provide a session id within a post request: userfull for flash based uploaders where authentication is required (done for www.xipax.com)

Being post-1.0 now, how is it going with the design descision? There are also related bugs, e.g. #6709 and #7167. The patches here actually look kind of good to me and I don't think that the SafeForms? discussed in #7167 will help for highly dynamic AJAX, so why not extend the CSRF middleware with these patches and add a nice and simple template tag to generate the token?

While this might not be the best solution ever, I'm still convinced that a lot of people will benefit from a "standard" solution to at least mitigate the problem in an easy way - the patches don't mess up too much and I think it's way better than having users develop their own hackish and potentially insecure method of extending the CSRF protection. Think of all the snippets and apps out there that are currently lacking a standard way of tackling this problem (e.g. threaded-comments, iirc).

This was fixed in [9554]