5 ms·

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'

by yoran 12y ago

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...

kelmop 12y ago
do you have any examples of this? this seems very interesting
voltagex_ 12y ago
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)
- yoran 12y ago
  Yep, here's the paper: http://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=summary.php&id=77 http://www.acsac.org/2012/openconf/modules/request.php?modul... It was presented at ACSAC 2012.
TazeTSchnitzel 12y ago
This is actually a large part of why ES5 added these things, to enable Caja and the like.
Mc_Big_G 12y ago
Reminds me of https://github.com/tildeio/oasis.js https://github.com/tildeio/oasis.js but not sure if it solves the same type of problem.
- yoran 12y ago
  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.
  - Cyril-sf 12y ago
    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).
deleted 12y ago
[deleted]

by yoran 12y ago

kelmop 12y ago

do you have any examples of this? this seems very interesting

voltagex_ 12y ago

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)

yoran 12y ago
Yep, here's the paper: http://www.acsac.org/2012/openconf/modules/request.php?module=oc_program&action=summary.php&id=77 http://www.acsac.org/2012/openconf/modules/request.php?modul... It was presented at ACSAC 2012.

TazeTSchnitzel 12y ago

This is actually a large part of why ES5 added these things, to enable Caja and the like.

Mc_Big_G 12y ago

Reminds me of https://github.com/tildeio/oasis.js https://github.com/tildeio/oasis.js but not sure if it solves the same type of problem.

yoran 12y ago
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.
- Cyril-sf 12y ago
  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).

deleted 12y ago

[deleted]