Hacker News Reader

Comment by mumrah | Hacker News Reader

Generally speaking, all incoming requests should be verified - authorized or not. These days with all kinds of wonderful web frameworks, CSRF protection is pretty simple. Django handles CSRF with a token in a hidden form field: https://docs.djangoproject.com/en/dev/ref/contrib/csrf/

View on HN

Wouldn't Oauth solve this, since all requests are signed?

Having a CSRF token on your forms does not prevent, and has nothing to do with, with the attack in the article.

Hi, why not? If the attacker can't get any information without sending a token with the request, what's there to worry about? I'm not very good with js so I might have misunderstood something. Thanks!

I believe that he's right that just putting it in a hidden form field would be useless for this sort of attack. However, I believe rails and django actually include the CSRF token in headers for ALL ajax requests, not just form submits.

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.

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?

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.

  > 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

This does not help at all in this case, proving that it is not that simple.

Reply on news.ycombinator.com