JSON users: Avoid CSRFs by not using top-level arrays • Hacker News Board

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

#81

Post by treyp » Sun, Jun 19, 2011, 7:44 PM UTC

sonnym wrote: post #5

timmorgan wrote: post #4

Earlier quoted context omitted.

OK, I see how that prevents an attack (it seems to create an endless loop), but how does this parse as regular JSON for the good guys?

I imagine they simply remove the first 8 characters from the response string. eval("(for(;;);{})"); doesn't work, but eval("(" + "for(;;);{}".substring(8, 10) + ")"); works fine where 10 is the length of the response string. EDIT: This is the correct idea. Search for shieldlen or safeResponse in the JS to see how it is implemented. There is always something interesting to be learned by digging through FB's client sid…

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

#82

Post by olliej » Mon, Jun 20, 2011, 12:52 AM UTC

The articles information is very out of date, and relies on multiple issues to successfully work:

  * It needs an array literal (eg. []) to be constructed using the function referenced by the Array property on the global object. (This was spec ambiguity and only effects older IE and Firefox -- very old firefox, maybe only up to netscape or phoenix?)
  * It needs assignments in object and array literals to call setters on the prototype chain.

Both of these issues were fixed by ES5 (the first may have been fixed in ES3.1) by saying that Array and Object literal notation both use the initial values of Array and Object (so you can't change the constructor used), and by saying that all assignments are "direct" so won't call setters on the prototype chain.

This effectively makes JSON hijacking impossible, except of course for the large numbers of old browsers that are out there.

This is also a distinct issue from JSONP hijacking, for which there isn't a solution other than to not use JSONP.

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

#83

Post by wladimir » Mon, Jun 20, 2011, 6:28 AM UTC

ams6110 wrote: post #80

espeed wrote: post #37

Earlier quoted context omitted.

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…

How much does running everything over HTTPS mitigate this cross-site stuff?

It doesn't. HTTPS mitigates passive sniffing and most MITM attacks but does not have any effect against cross-site script attacks such as CSRF and XSS.

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

#84

Post by pmh » Tue, Jun 21, 2011, 7:35 AM UTC

personalcompute wrote: post #56

tedunangst wrote: post #39

Earlier quoted context omitted.

Apache Extended Server Side Includes? Haven't seen XSSI before. What's the I? I agree, this is not the attack I think of when somebody mentions CSRF. Well, the solution at least isn't. I would be very suspicious of anyone who claimed to solve their CSRF holes by not using arrays.

Cross Site Script Inclusion. The article touches on a lot of things (including CSRF), but the HN title refers specifically to JSON (As well as the link's '#' fragment identifier), and therefore the last section, where it shows an attack site including unprotected JSON through the tag, and unless I'm seriously mistaken, this is the definition of XSSI.