Eval, literal eval, safe eval

[Florian Bösch]

On Sun, Nov 30, 2014 at 1:41 AM, Thaddee Tyl <thaddee.tyl at gmail.com> wrote:

> You can do a lot more. You can prevent the issues you point out (and
>
many others) by mocking all built-in object's prototypes that you want
> to feed the sandbox (so that modifications are actually performed on a
> throwaway prototype), and by removing all new properties that weren't
> there before and replacing those that were there before.
>
It was exemplary. Securing code is actually quite tricky unless you control
the VM it runs in. I believe a previous comment pointed this fact out.


> For all purposes, it is a safe eval. I really wish that Chrome would
> use it in their DevTools; I broke them so many times while writing
> this library that I have lost count. They actually use no sandbox at
> all in their [js console].
>
Could you elaborate on that point with some examples how you broke it?


> Most of that is (laborious but) easy. The thorny bit in localeval is
> passing values to the sandbox. While it obviously works in the version
> without a timeout (although infinite loops aren't protected against),
> the version with a timeout, which relies on web workers (or processes
> in node), doesn't pass non-JSON-serializable values fine.
>
You don't really want to serialize/deserialize everything. It is imminently
useful to be able to pass an object or function to a sandbox or receive one
out of it. Again, this is possible to do, but it's nearly impossible if
you're not in control of the VM (as is evidenced by your own
implementation).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141130/4712a350/attachment-0001.html>