Why does Google prepend while(1); to their JSON responses? | Hacker News Reader

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

stackoverflow.com

324 pointsgs752 comments

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.

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

There is a long discussion about this at

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

(from about a year 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 :(

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

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/

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

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

Example http://jsfiddle.net/V53BL

I can't get this to work with an actual API call.

    <script>
          Object.prototype.__defineSetter__('user', function(obj){alert('Hijacked!');console.log('Hijacked!', obj)});
          var trigger = [{"user":{}}];
     </script>
     <script id='current-user' src="http://my.secretapi.com/users/current"></script>

Where the API returns something like

    [{'user':{'name':'Joe Bloggs'}}]

(Un)Fortunately (depending on which side of this you're on...) they've plugged the holes?

It works on an explicit set, but not on initialization of the object. So:

var x = [{"user":"dude"}]; This won't trigger, and this is what the script include tag executes via the response.

x.user = "wow"; This will trigger, however.

And that's by design. That's how setters work. There's no security risk from this, given cross-domain JSON loads.

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.

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.

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

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.

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

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

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

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

bug doesn't exist anymore

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

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

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.

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.

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

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.

exactly. since normal script-tag cannot drop new X-Requested-With header, there's no need to add some "while(1)" things which look ugly.

There's downside, though - you can't inspect JSONs by simply opening them in a new tab.

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.

Hey Egor, article author here. How come you are not such a fan of checking referer? It cannot be a global fix (some sites depend on serving xdomain scripts, have lots of users with proxies that alter headers etc), but it should work well for many cases no?

it works of course, but to be compatible with many environments we need something more reliable than Referrer.

Sorry Egor, I thought you are pointing out an article you have published.

This is joev's article. His explanations of the issue are better than mine ;)

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

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.

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.

Why doesn't this prevent CSRF?

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.

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.

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

It's the bot.

Smart!

What?

The while(1) to defeat hot-linking.

Reply on news.ycombinator.com