JSON users: Avoid CSRFs by not using top-level arrays

Post by alanning » Sat, Jun 18, 2011, 11:02 PM UTC

arethuza wrote: post #46

alanning wrote: post #43

Earlier quoted context omitted.

Haacked has a step-by-step description of how this attack works: http://haacked.com/archive/2008/11/20/anatomy-of-a-subtle-js... The Microsoft asp.net web stack avoids this by automatically wrapping json responses with an object "{d:...}". The comments describe this as only affecting FF2.0 although testing was informal. (You should, of course, still protect your services.)

I think it's just the ASP.Net AJAX Toolkit not plain ASP.Net or ASP.Net MVC.

Post by locci » Sun, Jun 19, 2011, 12:08 AM UTC

the_mitsuhiko wrote: post #57

locci wrote: post #32

Earlier quoted context omitted.

Because [] is not syntactic sugar for new Array. The code the article wrote about doesn't work in any implementation that I know of. I think the ESv3 spec wasn't very clear: "Create a new array as if by the expression new Array()." But the implementations (always?) did the right thing, and the ESv5 spec is more clear: it adds "where Array is the standard built-in constructor with that name."

> Because [] is not syntactic sugar for new Array In Firefox 4 and other new browsers this is no longer the case. But right now it's still an issue as many people are using older browsers.

Post by personalcompute » Sun, Jun 19, 2011, 1:36 AM UTC

Jach wrote: post #71

personalcompute wrote: post #58

Earlier quoted context omitted.

Correct, the technical term for it is 'XSSI', or Cross Site Script Inclusion.

I haven't heard of that term before now, but I would argue that XSSI is a way of doing CSRF rather than CSRF, or something entirely different itself. (From Wikipedia: "Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.") Apologies if the title made it seem like not using javascript arrays was a magic bullet to prev…

Post by rimantas » Sun, Jun 19, 2011, 9:27 AM UTC

mmmm wrote: post #63

adamt wrote: post #50

Earlier quoted context omitted.

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 ( ). 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 s…

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?

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

Post by ams6110 » Sun, Jun 19, 2011, 6:15 PM UTC

espeed wrote: post #37

adolph wrote: post #6

I'm not familiar with CSRF so had to look this up: [Cross Site Request Forgery] vulnerabilities occur when a website allows an authenticated user to perform a sensitive action but does not verify that the user herself is invoking that action. The key to understanding CSRF attacks is to recognize that websites typically don't verify that a request came from an authorized user. Instead they verify only that the request…

A few days ago I asked, "Ask HN: Best Approaches to Prevent Session Hijacking?" ( http://news.ycombinator.com/item?id=2663293 ) and presented a technique I'm experimenting with that uses session timestamps as tokens to validate that each request is authentic and an attacker hasn't stolen the session key. It works by updating the token (timestamp) on the server and in the cookie on each request and they both have to m…