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: <a href="http://stackoverflow.com/a/16880162/372767" rel="nofollow">http://stackoverflow.com/a/16880162/372767</a><p>Also note that this attack, JSON Hijacking, is <i>different</i> than a CSRF (Cross Site Request Forgery) and has little to do with CSRF tokens.
There is a long discussion about this at<p><a href="https://news.ycombinator.com/item?id=5168121" rel="nofollow">https://news.ycombinator.com/item?id=5168121</a><p>(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 :(
A good description: <a href="http://stackoverflow.com/questions/6339790/what-does-a-ajax-call-response-like-for-json-data-mean" rel="nofollow">http://stackoverflow.com/questions/6339790/what-does-a-ajax-...</a><p>The idea: you need such workaround only if you return JSON Array.<p>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.<p><a href="http://docs.angularjs.org/api/ng.$http#description_security-considerations" rel="nofollow">http://docs.angularjs.org/api/ng.$http#description_security-...</a>
So does this solve the problem with using remote JS templates (advocated by DHH and 37s), what was outlined here [1]?<p>[1]: <a href="https://github.com/jcoglan/unsafe_sjr/blob/master/README.md" rel="nofollow">https://github.com/jcoglan/unsafe_sjr/blob/master/README.md</a>
Is it correct to use the Content-Type application/json on this? IMO: not.<p>(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. <a href="http://jsfiddle.net/KY4Sa/" rel="nofollow">http://jsfiddle.net/KY4Sa/</a>
Google is wrong IMO: there is no need to have such workaround. In rails we had similar problem <a href="https://community.rapid7.com/community/metasploit/blog/2013/12/29/remote-js--an-insecure-pattern-in-rails-code" rel="nofollow">https://community.rapid7.com/community/metasploit/blog/2013/...</a> and fixed it by adding request.xhr? check on server side.<p>while(1) is ugly solution to currently non-existing problem.