> 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...

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

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.

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.

Sorry, used the wrong term. I mean it can be injected as a script tag into an xdomain site.

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

Yeah it's a neat attack. pretty glaring info leak imho. Even an empty array response can expose login status

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

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

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.