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.
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.
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.
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.
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.
[0]: https://en.wikipedia.org/wiki/Cross-site_request_forgery
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.
... 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.
Yes, I'm being somewhat hyperbolic. Bring on the downvotes! ;-)
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.
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...
All sufficiently complex ecosystems are a giant, flawed mess.
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)
I believe that some browsers used to do that some times ago.
But getting hit with this, they would be actively hurt, and I don't think that interpreter session would be able to recover.
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...
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?
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.
Not necessarily, if all their API responses are top-level JSON objects.
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.
>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.
Yes, this works too. You’re correct about any keys causing a syntax error.
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.
> an AJAX request at mail.google.com
> will have full access to the text content,
> and can strip it away. function Array(){
alert("hello, I found something of yours!");
}
// ERROR: redeclaration of const Array
function Array() {console.log("hope")}
undefined
var x = new Array(3);
hope
undefined
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-...
It's fascinating to read how he discovered it and how quickly Google responded.
[1] - http://blog.jeremiahgrossman.com/2006/01/advanced-web-attack...