Why does Google prepend while(1); to their JSON responses?

http://stackoverflow.com/questions/2669690

by gs7 • 13 years ago

324 52 13 years ago

andreyf• 13 years ago

Does anyone know what browsers allow you to override the Array constructor? I was under the impression that modern browsers don't.

pygy_• 13 years ago

If the attacker knows the structure of the reply, `__defineSetter__` can be used to extract the JSON content as well. From [0]:

        <script type="text/javascript"> 
            Object.prototype.__defineSetter__('Id', function(obj){alert(obj);});
        </script> 
        <script src="http://example.com/Home/AdminBalances">/*Boom*/</script>

[0]: http://haacked.com/archive/2009/06/25/json-hijacking.aspx/

Jare2• 13 years ago

ES4 requires using the original, unmodified bindings. From a comment: http://stackoverflow.com/questions/16289894/is-json-hijackin...

primaryobjects2• 13 years ago

That's interesting. Apparently, the __defineSetter__ call is still valid in Chrome.

Example http://jsfiddle.net/V53BL

gsnedders2• 13 years ago

No current browser should be vulnerable to this (ES5 requires object literals use [[DefineOwnProperty]], not [[Put]], and hence no setter on the prototype chain should be called). I believe all browsers have since fixed this.

matchu3• 13 years ago

Here's a quick fiddle to check. This trick doesn't seem to work on Chrome 31. http://jsfiddle.net/g9R5s/

aboodman2• 13 years ago

I do not think this particular attack works in any modern browser anymore.

However, the while (1); (or similar tricks) is an easy defense-in-depth measure in case browsers regress in this area or new attacks are found.

matchu3• 13 years ago

It looks like modern Chrome doesn't trigger setters when constructing from literals, so that's encouraging. http://jsfiddle.net/KY4Sa/

frozenport• 13 years ago

What happens when you visit a malicious website and your computer gets stuck on `while(1)`? Syntax error would be better?

matchu3• 13 years ago

Because the script is useless, malicious websites won't bother including it, so the folks at Google don't really care what it actually does. Or, if the site wants to be malicious by just giving you a while(1), they can do that without Google's help.

Jare2• 13 years ago

I recall IE showed a dialog on javascript errors to ask if the user wanted to continue. An infinite loop will get the entire script aborted because there's no obvious way to continue.

Stealth-3• 13 years ago

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.

maxtaco• 13 years ago

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

smsm42• 13 years 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• 13 years 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...

jbri• 13 years ago

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

sanderjd• 13 years 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

joev_4• 13 years 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

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• 13 years 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.

Stealth-3• 13 years ago

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

alixaxel2• 13 years ago

Smart!

jbeja• 13 years ago

What?

alixaxel2• 13 years ago

The while(1) to defeat hot-linking.

Kiro• 13 years ago

Why doesn't this prevent CSRF?

yelnatz• 13 years ago

CSRF is different from JSON hijacking, but they're closely related.

This only prevents attacks that uses a script to execute a get method and returns a JSON array.

JSON arrays can be "executed" as if it was javascript. The attack relies on modifying what javascipt does when this faux script is ran.

So if you put a "while(1);" in there, it prevents it from finishing. Thus preventing the exposure of the sensitive data.

It's similar to CSRF since that attack relies on the user to have an active session to be able to access sensitive data, but they differ in MO.

evan_• 13 years ago

This is specifically dealing with reading results from a remote script- with a CSRF you often (usually? Always?) don't care about the result, because the damage has been do e by the time you are successfully able to send an authenticated request.

robocat• 13 years ago

Would introducing a syntax error into my JSON help prevent CSRF attacks? We don't use JSONP.

homakov7• 13 years ago

bug doesn't exist anymore

ciniglio• 13 years ago

So does this solve the problem with using remote JS templates (advocated by DHH and 37s), what was outlined here [1]?

[1] https://github.com/jcoglan/unsafe_sjr/blob/master/README.md

homakov7• 13 years ago

it does, but it's worst workaround. we chose request.xhr? check

homakov7• 13 years ago

Google is wrong IMO: there is no need to have such workaround. In rails we had similar problem https://community.rapid7.com/community/metasploit/blog/2013/... and fixed it by adding request.xhr? check on server side.

while(1) is ugly solution to currently non-existing problem.

tzury3• 13 years ago

Does your solution assumes referrer will not be manipulated on the client side?

homakov7• 13 years ago

my solution is request.xhr? check. the link above is only to explain what rails-bug was. I don't think checking referrer is a good idea there.

Stealth-3• 13 years ago

I imagine it assumes a header like X-Requested-By has not been manipulated. You can safely assume that the referrer, or other headers, have not been manipulated. There is no way for malicious Javascript running in the users browser to edit headers.

Of course, anyone can code their own browser to lie about headers. It doesn't make much sense to specifically open yourself to vulnerabilities though.

aboodman2• 13 years ago

When you have n-hundred-million people's personal information at stake, 'currently non-existing (but multiple-times previously existing)' is not very reassuring. There's nothing wrong with multiple layers of safeguards.

tzury3• 13 years ago

There is a long discussion about this at

https://news.ycombinator.com/item?id=5168121

(from about a year ago)

frik2• 13 years ago

Facebook uses "for(;;);" as it's one char shorter.

frik2• 13 years ago

Chrome DevTools recognice while(1) and for(;;) in the network tab (JSON preview). Sadly, Firebug still doesn't know how to handle this and shows no JSON preview :(

silon3• 13 years ago

Is it correct to use the Content-Type application/json on this? IMO: not.

(I've just tested Firefox network view and it breaks the response display with syntax error -- there should be an option to select the format).

dontdownload• 13 years ago

It's the bot.

jbrackett• 13 years ago

After seeing this I went to see if AngularJS had anything built in to mitigate JSON hijacking and they do. It will strip ")]}',\n" off of json responses if included from the server.

http://docs.angularjs.org/api/ng.$http#description_security-...

CCs• 13 years ago

A good description: http://stackoverflow.com/questions/6339790/what-does-a-ajax-...

The idea: you need such workaround only if you return JSON Array.

Most of the API returns JSON Object in which case the attack does not work, it will result in syntax error.

Why does Google prepend while(1); to their JSON responses?

Related Stories