23 ms·

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 scri

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

maxtaco 13y ago
I think Jakub P. was implying that the CSRF-token defense could also guard against this attack.
smsm42 13y ago
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.
deathanatos 13y ago
> 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/Ecma-262.pdf http://www.ecma-international.org/publications/files/ECMA-ST...
- jbri 13y ago
  Of course, the reason that language was introduced into the standard was primarily to mitigate this sort of attack.
sanderjd 13y ago
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 https://github.com/jsanders/angular_rails_csrf/issues/1
joev_ 13y ago
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 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 13y ago
  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.
  - joev_ 13y ago
    Sorry, used the wrong term. I mean it can be injected as a script tag into an xdomain site.
- Stealth- 13y ago
  VERY interesting, thanks for sharing! I'll have to play around with this a bit...
  - joev_ 13y ago
    Yeah it's a neat attack. pretty glaring info leak imho. Even an empty array response can expose login status

maxtaco 13y ago

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

smsm42 13y ago

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.

deathanatos 13y ago

> 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/Ecma-262.pdf http://www.ecma-international.org/publications/files/ECMA-ST...

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

sanderjd 13y ago

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 https://github.com/jsanders/angular_rails_csrf/issues/1

joev_ 13y ago

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 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 13y ago
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.
- joev_ 13y ago
  Sorry, used the wrong term. I mean it can be injected as a script tag into an xdomain site.
Stealth- 13y ago
VERY interesting, thanks for sharing! I'll have to play around with this a bit...
- joev_ 13y ago
  Yeah it's a neat attack. pretty glaring info leak imho. Even an empty array response can expose login status