a future caller alternative ?

Kevin Reid kpreid at google.com
Mon Mar 11 13:51:40 PDT 2013

On Mon, Mar 11, 2013 at 12:56 PM, Brandon Benvie <bbenvie at mozilla.com>wrote:

>  On 3/11/2013 12:41 PM, Kevin Reid wrote:
> Yes, taking care of all those things is necessary as well. ES5 provides us
> the tools to do so: Object.freeze(). If you recursively freeze all standard
> global objects then all of the issues you mention are handled. Secure
> ECMAScript (SES), developed by Mark Miller, does this; it provides an
> execution environment which _is_ secure (given a sufficiently conformant
> ES5 implementation).
> I would note, however, that it looks like at, least in browsers, freezing
> the window or even any single property on it will no longer be an option in
> the future. I believe the technique used by SES (correct me if I'm wrong)
> is using is more complex than simply freezing the window (though I believe
> it does freeze every property recursively from there).

Right. We construct an object which has the bindings specified by ES5
(Object, Array, parseInt, ...), but not the DOM (document, window,
HTMLElement...). Actual access to the DOM by untrusted code is done with
intermediation and is not part of SES per se. Trying to turn window itself
into a sandbox is a non-starter.

> Something like shadowing all whitelisted global names and preventing any
> kind of direct access to the window object at all. This requires some
> amount of source code sandboxing to accomplish.

The minimal solution is to (conservatively) find all (potential) free
variables in the source code and bind them, which we currently do using an
outer 'with' statement (in order to be able to intercept accesses using
accessor properties, for best emulation of legacy global-variable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130311/3d0da600/attachment.html>

More information about the es-discuss mailing list