Google use cookies to authenticate API requests?
Why does Google prepend while(1); to their JSON responses?
31–40 of 120 posts
Re: Why does Google prepend while(1); to their JSON responses?
#32FB 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)
Why does it have to be a loop, couldn't you make a reliable syntax error in less than 8 characters?
Re: Why does Google prepend while(1); to their JSON responses?
#33Everytime 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.
Re: Why does Google prepend while(1); to their JSON responses?
#34Earlier quoted context omitted.
Why does it have to be a loop, couldn't you make a reliable syntax error in less than 8 characters?
8 chars is already pretty short. If you're concerned about the length, don't be. A TCP packet is at least 512 bytes.
Re: Why does Google prepend while(1); to their JSON responses?
#35Why don't browsers strip cookies when they are doing cross domain javascript fetches?
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)
Re: Why does Google prepend while(1); to their JSON responses?
#36Earlier quoted context omitted.
Why does it have to be a loop, couldn't you make a reliable syntax error in less than 8 characters?
8 chars is already pretty short. If you're concerned about the length, don't be. A TCP packet is at least 512 bytes.
Re: Why does Google prepend while(1); to their JSON responses?
#37Earlier quoted context omitted.
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.
But an attacker would simply use https://.." , instead of <script src="httpsb://.." ?
Re: Why does Google prepend while(1); to their JSON responses?
#38Why don't browsers strip cookies when they are doing cross domain javascript fetches?
Re: Why does Google prepend while(1); to their JSON responses?
#39Why don't browsers strip cookies when they are doing cross domain javascript fetches?
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.
Re: Why does Google prepend while(1); to their JSON responses?
#40Earlier quoted context omitted.
8 chars is already pretty short. If you're concerned about the length, don't be. A TCP packet is at least 512 bytes.
An extra character will cause 1/512 of responses to take an extra packet, so the amortized cost is still one character per response. Presumably this matters at scale.
If your responses are all between 505 and 512 in length then it might matter but most likely you are prematurely optimizing.