It was only last week or so when I read some security researcher pulling some tricks to bypass part of caja's sandbox (while looking for something else, even). Sure this was a whitehat researcher and they got a (very) nice bug bounty from Google Project Zero. But if they use this to secure the 3rd party scripts that are apparently allowed these days on Google Ads, they're being hugely irresponsible.
I never heard of Caja until a few weeks ago, but apparently it started in 2007, could be that I forgot when I heard about it though. Back in 2007 though I was still a frontend web developer with a very keen eye on JS security and all the XSS/CSRF problems of those days. Back then JS/ECMAScript did not have sufficiently advanced features to properly sandbox code. This was a bit of a fool's errand back then. By now it's gotten a lot more of these features, mainly revolving around protecting the super-flexible fluid JS objects from modification and abuse. But I really kind of wonder if that locks everything really watertight? Because browsers are going to have unofficial/proprietary features, and you need just one to accidentally get this slightly wrong, get a reference to a non-sandboxed Window object via-via-via, and it all falls apart.
You don't let untrusted people run code on stuff you serve. Code is just too slippery, turing complete etc, and ECMAScript perhaps even more so than many other languages. Can't we just take that for a given by now, instead of trying to be cleverer than the previous smart person that failed at it?
Sort of: I don't think it's meant to restrict time/space usage, just access to capabilities. If you don't give the ad-code access to the network, it'd have no way to access the blockchain, but it could still chew up your CPU cycles.
I never heard of Caja until a few weeks ago, but apparently it started in 2007, could be that I forgot when I heard about it though. Back in 2007 though I was still a frontend web developer with a very keen eye on JS security and all the XSS/CSRF problems of those days. Back then JS/ECMAScript did not have sufficiently advanced features to properly sandbox code. This was a bit of a fool's errand back then. By now it's gotten a lot more of these features, mainly revolving around protecting the super-flexible fluid JS objects from modification and abuse. But I really kind of wonder if that locks everything really watertight? Because browsers are going to have unofficial/proprietary features, and you need just one to accidentally get this slightly wrong, get a reference to a non-sandboxed Window object via-via-via, and it all falls apart.
You don't let untrusted people run code on stuff you serve. Code is just too slippery, turing complete etc, and ECMAScript perhaps even more so than many other languages. Can't we just take that for a given by now, instead of trying to be cleverer than the previous smart person that failed at it?