[adamt]

The Django "{% csrftoken %}" that you put into forms (and similar things in other frameworks), is used when posting form responses. It turns into a hidden form field (<input type=hidden>). This helps protects against someone creating a form on their own malicious site, that posts some data to yours.

This attack mentioned in the OP is effectively completely different. It is off a GET request.

Imagine you were running a social network site, and you had an API (authenticated via HTTP sesions) that was a GET request go get the firends list. This method returned the (logged-in) users list of friends in a JS array.

Note that Django-style CSRF tokens are not relevant here, as they are only for protecting POSTs.

The attack described in the post is using a script tag, and a redefined array setter, to direct a user with a live logged-in session on your site to it to fetch data.

So coming back to my example. I am a malicious hacker, and I can socially engineer an end-user to come to my site. I put a script src=yoursocialnetwork.com/get_friend_list. This will fetch the data, and I will be able to extract that info in my javascript, and then post that back to my site so I can capture that info.

[mmmm]

Thanks a lot for the excellent explanation. I tend to do my Ajax requests with post just to get the token in. Is there a reason not doing so, like savings in bandwidth or something like that? Might that be a gain Facebook is trying to achieve?

[rimantas]

  > Is there a reason not doing so, like savings in bandwidth or something
  > like that?

GETs may perform slightly better, see http://developer.yahoo.com/performance/rules.html#ajax_get

[squeed]

Yours is a good solution, and effectively blocks the attack mentioned in this article. From a REST purity standpoint, it's "unclean" to require all API calls to be POSTS, but, hey, life is short.