I once participated in a web security research project where we used ES6 Proxies to sandbox third-party scripts, basically controlling what DOM operations they're allowed to do in a whitelist. This is relevant when you include sketchy advertisement scripts or scripts you don't trust (e.g. "trusted" scripts but delivered through an untrusted CDN). By default, no operations were allowed and by whitelisting until there were no more errors, we managed to effectively completely sandbox jQuery, Google Maps and Google Analytics. None of these scripts were allowed to execute more operations than the ones exactly required for them to function. Proxies were an elegant way to intercept getters and setters on window, document, location, etc...
Are you able to link to the research? It sounds like a native-JS version of NoScript, which is really interesting (apologies to the dead comment under me which asked something similar)
This is interesting, I hadn't heard of Oasis.js. Both approaches try to solve the same problem, i.e. manage to sandbox third-party scripts. However, the implementation is different: oasis.js uses iframes, we chose for not using iframes, mainly because iframes are not enough to limit access to security-sensitive APIs such as XHR, Geolocation and local storage.
One constraint for Oasis.js when picking a technology was the compatibility with IE8. So we use modern technology everywhere we can, but we have to find a way to polyfill them for older browsers (mostly IE8/9).
Comments
I once participated in a web security research project where we used ES6 Proxies to sandbox third-party scripts, basically controlling what DOM operations they're allowed to do in a whitelist. This is relevant when you include sketchy advertisement scripts or scripts you don't trust (e.g. "trusted" scripts but delivered through an untrusted CDN). By default, no operations were allowed and by whitelisting until there were no more errors, we managed to effectively completely sandbox jQuery, Google Maps and Google Analytics. None of these scripts were allowed to execute more operations than the ones exactly required for them to function. Proxies were an elegant way to intercept getters and setters on window, document, location, etc...
Are you able to link to the research? It sounds like a native-JS version of NoScript, which is really interesting (apologies to the dead comment under me which asked something similar)
Yep, here's the paper: http://www.acsac.org/2012/openconf/modules/request.php?modul...
It was presented at ACSAC 2012.
This is actually a large part of why ES5 added these things, to enable Caja and the like.
Reminds me of https://github.com/tildeio/oasis.js but not sure if it solves the same type of problem.
This is interesting, I hadn't heard of Oasis.js. Both approaches try to solve the same problem, i.e. manage to sandbox third-party scripts. However, the implementation is different: oasis.js uses iframes, we chose for not using iframes, mainly because iframes are not enough to limit access to security-sensitive APIs such as XHR, Geolocation and local storage.
One constraint for Oasis.js when picking a technology was the compatibility with IE8. So we use modern technology everywhere we can, but we have to find a way to polyfill them for older browsers (mostly IE8/9).