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

http://stackoverflow.com/q/2669690/1922352

by vikas0380 • 9 years ago

598 110 9 years ago

stackoverflow.com

samfisher832• 9 years ago

Why don't browsers strip cookies when they are doing cross domain javascript fetches?

Tloewald2• 9 years ago

I'd say it's because of advertising mostly, but a lot of similar tech (that is usually ad supported) like Disqus.

It's interesting that today cross-domain sandboxing applies to almost everything except JavaScript. If I load an image cross domain and draw it into a canvas, the contents of that canvas are sandboxes, but I can cheerfully mix and match code across domains too.

Seems like it would be a good thing to do but it would break a ton of stuff.

samfisher832• 9 years ago

Having advertisers not tracking you seems like a benefit not a con.

vbezhenar• 9 years ago

Because that's the way internet works and breaking it means breaking a lot of websites. Web security wasn't thought carefully when web was built, it's just a bunch of dirty hacks around most obvious vulnerabilities.

captainmuon• 9 years ago

It would be easy to make sending credentials opt-in in a new HTTP or HTML version. The way it's done now is backwards IMHO.

Define httpsb:// do be like https://, but any site may make ajax and similar requests to it (without credentials). Then make some kind of exception (like csrf protection), or use legacy https, in case you need to send cookies.

amelius3• 9 years ago

I guess this is what you get if you let an advertisement company define the web.

amelius3• 9 years ago

Can I turn this off?

kalleboo• 9 years ago

Isn't that what Safari does with the "Allow from current website only" setting? It defaults to "Allow from websites I visit", which means that only embedded content from sites you've visited before get their cookies, not random new embeds)

hoschicz• 9 years ago

Interesting. Dos that mean that trackers like doubkeclick don't work on Safari with the default settings?

extrapickles• 9 years ago

There is a newish cookie flag called samesite to do exactly this. Chrome is the only browser to support it though.

kylebebak2• 9 years ago

I read about this recently. It's hard to believe these cookies didn't exist until 2016.

The biggest problem solved by cookies has always been sessions. samesite is sufficient for most sessions. It seems like samesite should have been the default from the beginning.

LoSboccacc• 9 years ago

Because not all websites can federate their users

niftich• 9 years ago

Lack of focus, despite many years of research, literature, and attempts; interference with problematic techniques that have become really popular when alternatives sucked, like JSONP before CORS was ready, and before C-S-P was even thought of; worry about touching parts of the platform that have essentially been unchanged since the beginning vs. those parts that are fairly new and have in turn evolved quicker.

On subject of the new SameSite cookie, I wrote a post that summarized my views [1]; it doesn't make for good quoting, but I briefly recount the history of CSRF and how its mainstream knowledge came around 2006-2008, some 5 years after the first sources that mention mitigating against it -- but a 2008 academic paper on it credits "(...) Chris Shiflett and Jeremiah Grossman for tirelessly working to educate developers about CSRF attacks (...)" -- Shiflett being same person who first wrote about this in 2003, and Grossman the one who discovered this flaw in Gmail in 2006.

[1] https://news.ycombinator.com/item?id=13691022

blntechie• 9 years ago

It's not the same but aren't the httpOnly cookies kind of serve the same purpose? JS can't read these cookies at all?

hdhzy6• 9 years ago

JS can't (that protects against stealing the token) but the server still receives it even when the request originates from foreign domain. That's the gist of CSRF [0].

[0] https://en.wikipedia.org/wiki/Cross-site_request_forgery

ubernostrum• 9 years ago

Because then they end up with a bug in how they do it, and oops.

When developing web applications, you must approach this from the perspective of "what is the oldest, least-secure, most bug-riddled pile of C++ and plugins someone could try to hit this with".

If you want an example of why this has to be the approach, well... six years ago the Django security team got an email from the Rails security team. Turned out something we'd both done in our CSRF protection systems didn't actually work. Protecting against CSRF while allowing XMLHttpRequest (remember this is 2011!) is kind of tricky, and the standard approach was one adopted by a lot of JavaScript toolkits: they'd set a consistent custom header (X-Requested-With) on the request. And since browsers only allowed that to be done on requests which obeyed the same-origin sandbox, it was reliable: you knew if you saw that header, it was an XMLHttpRequest that a browser had vetted for same-origin safety (or that it was someone faking a request outside of a browser, but that's not a CSRF vector).

And then it turned out that thanks to a bug in Flash plus the way browsers handled a certain obscure HTTP status code, you could actually set that header on a request to any domain. Oops, that's a complete CSRF bypass in Rails, Django and I don't even remember how many other things.

That's how we learned that particular lesson about trusting browsers to do the right thing, and I don't see myself ever trusting browser security like that again.

CaliforniaKarl• 9 years ago

I haven't worked with JSON like that before. Do JSON parsers properly ignore the stuff Google puts in, or do you have to strip it out before parsing?

RKearney• 9 years ago

In the very first stack overflow answer:

  > an AJAX request at mail.google.com
  > will have full access to the text content,
  > and can strip it away.

zoren• 9 years ago

That is one weird array in Google's reply. Looks like it could have been an object instead, whereby JSON hijacking wouldn't be a problem.

frik• 9 years ago

FB prepends a "for(;;);" which is 1 char shorter than "while(1);", has been the case since 2012/13.

Firebug v2 and ChromeTools know how to parse such JSON and ignore that first part. (IE11 and Firefox newer DevTools can't "handle" it aka show just a plain text string)

Lxr3• 9 years ago

Why does it have to be a loop, couldn't you make a reliable syntax error in less than 8 characters?

CJefferson2• 9 years ago

The risk there is some parsers might carry on past the syntax error and try to continue parsing. This is JavaScript after all.

coldtea2• 9 years ago

The offending website could have error handling to catch and discard the syntax error (e.g. global uncaught exception handler). They wont be able to read the JSON, but otherwise they'd be OK.

But getting hit with this, they would be actively hurt, and I don't think that interpreter session would be able to recover.

jcoffland2• 9 years ago

8 chars is already pretty short. If you're concerned about the length, don't be. A TCP packet is at least 512 bytes.

scotth• 9 years ago

You can, and Google does. For example:

https://fonts.google.com/metadata/fonts

And here's the code in Angular's $http service for stripping out that string:

https://github.com/angular/angular.js/blob/master/src/ng/htt...

fooyc• 9 years ago

The browser may disclose part of the JSON content in a "parse error" error message. A window.onerror handler could catch this message.

I believe that some browsers used to do that some times ago.

cpeterso• 9 years ago

'for(;;);' probably compresses better than 'while(1)' too. Semicolons are (very :) common in JavaScript code and the for idiom repeats them three times.

winteriscoming• 9 years ago

Everytime I read about such constructs, it makes me realize, as a regular developer, how complex web application security is and how difficult it is to think about and cover your application against each and every such potential problem.

hdhzy6• 9 years ago

Note that these protections are only needed because Google supports every imaginable browser version even outdated ones. You most certainly do not need to do the same.

Array and object globals cannot be overridden now (since 2007) for literals [0] and for ambient authority problem with CORS just check the Origin header.

[0] https://johnresig.com/blog/re-securing-json/

emmelaich• 9 years ago

That would a good note to add to that StackOverflow question.

fixermark• 9 years ago

You most certainly do not need to do the same.

... except that those browsers are still out there, so it depends heavily on how much damage someone can do by abusing the data your server can emit whether you need to do the same.

winterlight• 9 years ago

Modern web development is already hard by itself, specially when it comes to security. A saner runtime language is needed to replace the sub par standard that is javascript. One with a robust type-system and coherent semantics. It won't fix every problem, but a least it would prevent abuses such as the one in question.

vesinisa2• 9 years ago

WASM (WebAssembly) is about developing a very simple cross-browser bytecode that allows implementing any runtime on top of it. The first versions are already rolling out in latest major browser versions, but at this stage you don't yet get DOM access from WASM. After the initial phase when DOM access is implemented, it's the beginning of end for JavaScript. Future browsers might well implement JS as a pre-shipped runtime targeting the internal WASM core.

trav4225• 9 years ago

Yup! In my personal (and basically worthless) opinion, this is why the entire "web application" ecosystem is a giant, flawed mess. It's basically what happens when a system originally designed to represent and transfer rich textual documents (HTML/HTTP) is bastardized into a application architecture.

Yes, I'm being somewhat hyperbolic. Bring on the downvotes! ;-)

peterwwillis• 9 years ago

It's worse than that. Because better solutions were "hard" or long-term and competing organizations couldn't agree on shared standards, they took an application and protocol designed to traverse documents, and built on complex hacks until it essentially became a pseudo-operating system, which now not only drives part of the global economy, but also changed the type and quality of information that most people receive.

ng12• 9 years ago

It's a moot point. Very few professional web application developers would disagree with you. The problem is this is the world we live in and if you don't develop web applications in the consumer space you'll get eaten alive by your competitors who will.

TheAceOfHearts• 9 years ago

This problem isn't limited to web applications. Think about how many security problems happen on the server.

All sufficiently complex ecosystems are a giant, flawed mess.

ef4• 9 years ago

This kind of criticism misses the point. The web is not designed. It is evolved. Various bits of it were designed at their outset, but it was literally impossible to envision all the implications of those design decisions.

This is not a bad thing, for the simple reason that every long-lived complex system involving many humans must behave this way.

Any attempt to top-down design the perfect, universal, distributed application runtime hits fundamental social problems not unlike those in a centrally planned economy: too much information to integrate, too many stubbornly uncooperative humans with their own divergent goals and opinions.

Systems at this scale are much more like biology than like circuit design.

kylebebak2• 9 years ago

I like to think web browsers take the worse is better approach to security.

Security takes a back seat to reproductive fitness of the web as a platform. JS made the web insecure, but it also made it the world's premier application platform.

I blogged about this: http://kylebebak.github.io/post/browser-security-worse-is-be...

ehsankia• 9 years ago

You're basically letting strangers run code on your computer. That's basically what a "website" is. It is truly impressive to me how we can have something so complex and still manage to somehow keep it (usually) secure.

moron4hire• 9 years ago

That's what "software" is, dude.

nullnilvoid• 9 years ago

Indeed, there are so many traps you can fall into when writing web apps. It feels like when web was designed, security was not given due attention and efforts.

westoque• 9 years ago

I wondered the same thing years ago. I always thought that browsers would have implemented other security measures so that websites avoid doing this.

Around 90 something percent of websites I visit don't implement that `for(;;)` or `while(1)` solution.

So are we saying that they're vulnerable sites?

Lxr3• 9 years ago

The root object has to be an array I believe.

coldtea2• 9 years ago

So are we saying that they're vulnerable sites?

We are saying that they're vulnerable for THAT particular issue (the JSON hijacking), and that is only if they don't already have some other way of dealing with it.

raulk• 9 years ago

So are we saying that they're vulnerable sites?

Not necessarily, if all their API responses are top-level JSON objects.

minitech5• 9 years ago

No, they’re not vulnerable; browsers fixed this bug a long time ago.

xg152• 9 years ago

I had a hunch that this is to prevent people from including the resource in a script tag - but I always wondered how they'd access the data as a JSON expression on its own should technically be a no-op when interpreted as JS (or so I thought).

The overridden array constructor was the missing link.

Though couldn't you have it easier by making sure your top-level JSON structure is always an object?

As far as I know, while a standalone array expression []; is a valid JS statement, a standalone object expression {}; is not and would produce a syntax error.

Lxr3• 9 years ago

.NET does this by wrapping things with {'d': data}, I always thought this was the reason.

eriknstr• 9 years ago

Someone had the same question as you in a comment.

Wouldn't returning an object containing the array, instead of the array directly, also solve the problem?

And someone else replied

No, that wouldn't solve the problem since the same attacks mentioned in the post could still be performed. Overriding the accessor methods to retrieve the info.

wtetzner2• 9 years ago

Except I don't think a JSON object is valid Javascript by itself.

minitech5• 9 years ago

Though couldn't you have it easier by making sure your top-level JSON structure is always an object?

Yes, this works too. You’re correct about any keys causing a syntax error.

c0achmcguirk• 9 years ago

I believe this hack (JSON Hijacking) was discovered by Jeremiah Grossman in 2005[1].

It's fascinating to read how he discovered it and how quickly Google responded.

[1] http://blog.jeremiahgrossman.com/2006/01/advanced-web-attack...

NewEntryHN• 9 years ago

Google use cookies to authenticate API requests?

stanleydrew• 9 years ago

Not sure if they do, but why not? It's just an opaque token in the HTTP request content, same as any other opaque token.

Animats• 9 years ago

Why not "while(0)"? Then an eval wouldn't do anything.

orf• 9 years ago

Because it's not about eval(), as the link you're commenting on explains in detail?

adrianmalacoda• 9 years ago

If I'm understanding it correctly, though, prepending while(0) or even if(0) to the JSON would prevent the attack, because the JSON object would not actually be executed. I think they were asking if there was any particular reason to prefer the infinite loop over that.

The answer that comes to mind for me is that having the script hang is a more obvious failure state than simply skipping over the statement, and makes it more immediate that something has gone wrong.

tossaway322• 9 years ago

Jeez, why not live w/o JavaScript?

We keep trying to accomodate a defunct language with insoluble problems. Isn't that an error in our thinking processes?

https://www.wired.com/2015/11/i-turned-off-javascript-for-a-...

_pmf_2• 9 years ago

Not only that. They keep piling on new shit APIs. Half of the WebGL exploits are probably yet unveiled, there's a side channel attack using the new ambient light sensor API, but hey, my phone can get darker based on ambient light, hooray!

the_mitsuhiko• 9 years ago

Pretty sure browsers no longer permit overriding ctors for literals.

gavinpc2• 9 years ago

The John Resig post linked by TFA indicates that this was originally dealt with by locking the constructor altogether:

   function Array(){
     alert("hello, I found something of yours!");
   }
   // ERROR: redeclaration of const Array

But it appears that the restriction now applies only to literals, as I can do this in at least Chrome and Firefox:

    function Array() {console.log("hope")}
    undefined
    var x = new Array(3);
    hope
    undefined

https://johnresig.com/blog/re-securing-json/

maambmb• 9 years ago

I feel like the browser could use the Content-Type header to check whether the response is JSON or actual executable javascript - throwing an error if the former

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

Related Stories