[Stealth-]

I think it's important to note that this is a bug that effects older browsers only. Modern IE, Chrome, and Firefox have security measures that do not allow scripts to capture values passed to constructors of a literal. That way, this hack is only needed for older browsers and will hopefully not be needed at all in the future. For more info: http://stackoverflow.com/a/16880162/372767

Also note that this attack, JSON Hijacking, is different than a CSRF (Cross Site Request Forgery) and has little to do with CSRF tokens.

[deathanatos]

> Modern [browsers] have security measures that do not allow scripts to capture values passed to constructors of a literal.

Actually, it's not security measures so much as implementing ECMAScript 5, which explicitly says that array literals must use the built-in constructor, not any override. See 11.1.4 [1], which reads:

> Let array be the result of creating a new object as if by the expression new Array() where Array is the standard built-in constructor with that name.

Object works similarly, and is in 11.1.5. I'm not certain what earlier standards said here, but I suspect they didn't say anything.

[1]: http://www.ecma-international.org/publications/files/ECMA-ST...

[jbri]

Of course, the reason that language was introduced into the standard was primarily to mitigate this sort of attack.

[joev_]

Actually, ie is still vulnerable to a very similar attack in some cases, specifically you can leak responses containing small json array by inlining the json as a script[src=vbscript] tag. Disclosed here: http://en.wooyun.org/bugs/wooyun-2013-023

with the status "unable to contact the vendor or actively neglected by the vendor" :-/

Edit: I meant "injecting" not inlining. Thanks chc for pointing that out.

[chc]

If it has to be inlined, how is that the same vulnerability? I thought the vulnerability was that script tags can fetch external scripts and a local script intercept the results. If you have to inline both scripts, you can only attack yourself.

[Stealth-]

VERY interesting, thanks for sharing! I'll have to play around with this a bit...

[sanderjd]

Wow, I was just having this discussion on an issue for a CSRF protection gem[0]. From what I can tell, IE wasn't even susceptible to this (perhaps accidentally) as far back as 6, and it's been fixed in Firefox since 3.1, and Chrome around the same time. I've been wanting to run a test case against a bunch of browsers to prove it to myself, but this seems to be a complete non-issue nowadays.

0: https://github.com/jsanders/angular_rails_csrf/issues/1

[maxtaco]

I think Jakub P. was implying that the CSRF-token defense could also guard against this attack.

[smsm42]

Well, one thing to do with the tokens might be that if the token were required for the GET request in question, then stealing the content via script tag may be harder. OTOH, putting one-time tokens on every request might be a bit too much for many apps, while(1) hack may be more efficient.