A Case for Safe Eval

Rather than trying to sanitize the input to 'eval', why not just write a separate expression evaluator? Then you can know for sure that there's no way to craft an input that causes an arbitrary function call, because your evaluator has no way to make an arbitrary function call. Also, you can define whatever operators you like.

This use case doesn't seem to me to be one that's likely to arise often.

> Additionally, (() => 5)() doesn't work because we don't allow open and close parens next to each other.

Not really, I can write

  ((/**/)=>5)(/**/)

Using eval on data that are provided by a user is always a bad idea. You cannot be sure that your sanitiser will be safe with new syntax elements.

> This is very quickly becoming a huge pain for me to write. I have to write a compiler, and a lexer. I have to continue extending this for each new kind of operator added.

Counterpoint: good luck getting that magical regex to scale to many new operators. Or other data types, for that matter. What if, for instance, you wanted to add support for strings? Suddenly, the entire original approach is useless and building a tiny compiler is the best and safest option.

It also the case that, as olegbulatov demonstrated, you're fighting an uphill battle trying to sanitize code with a regex. There's really not reasonable way to prove with 100% certainty that a regexp blocks _all possible expressions_ that could do nasty things. Writing a tiny compiler might be a pain in the ass, but you can be very sure of the safety that it offers....and it doesn't need to use eval().

This seems like just another form of string trepanation: https://thoughtstreams.io/glyph/string-trepanation/

You're trying to get the evil out of the string, at which point the remainder of the string is good. That's not how strings work. If it happens to work now, who knows what syntax will show up next year (and there are plenty of examples on this page of working around the regex). You're in a constant battle of figuring out whether bytes are good or evil when the actually answer is they're neither.

Full recognition before processing! http://langsec.org/occupy/

In the E family, cousins to ECMAScript, the eval() function is confinement-safe and cannot access objects which it hasn't been given explicit access to use. The proof actually can be extended to any lambda calculus which doesn't have global mutable state.

Edit: I should add that the crux of the technique involves a two-argument eval() with an explicit environment, as opposed to the single-argument eval() of ECMAScript.

So we restrict it to a subset that you can’t figure out how to exploit? How reassuring.

This idea is neat, and the article does a good job of highlighting some of the potential evil and potential good of eval. However, as many other commenters have pointed out, it's far from a complete or trustable solution--and even if it's good enough for now, it may not be good enough for the JS of tomorrow (this language iterates bloody fast).

Far better would be a capability-based sandbox API in the browser (like the Node.JS one: https://nodejs.org/api/vm.html#vm_vm_createcontext_sandbox_o...) that also supports filters like "stack depth" to limit infinite recursion, and/or some sort of opcount to limit other nonterminating functions. Combine those two things, and you have at least a way to secure arbitrary code you want to eval.

I think that most people with a real/non-insane need for such a service would be willing to pay a fair amount of performance (e.g. introducing an Erlang-esque reduction count idea to code inside the sandbox) to get it working safely.

Mind you, even if that existed it'd be hard to use correctly; people would try to safe-eval code, fail, and open up over-promiscuous capabilities (just like redis: http://antirez.com/news/118), putting us back at square one. For many purposes, though, it would be a very interesting and powerful tool when wielded carefully.

While fun, I do hope this is a joke, since as other comments have said, it’s fairly straight-forward to make a DSL for the given problems that this could solve. Beyond that, this would never be safe from syntax mutations in new versions of ECMAScript and sadly would cause issues similar to the recent smoosh controversy (where a common library implemented `flatten` in a way that was incompatible with the new ES specification).

Title should be:

> A Case for Safe Eval

The author's argument is that there is at least one valid use case for eval, not that it belongs in all web projects.

At this point, why not just implement a restricted interpreter in JS with a simple language. As soon as you do anything non-trival you're going to want variables and function calls.

I see why it doesn’t allow their example of “(() => 5)()”

But what is preventing me from doing “((a) => 5)(0)” since the regex only requires at least one non space char between parens...

Or any function call really?

Maybe the author of this could provide a web page that allows anybody to enter "safe" JavaScript.

Provide a $10 prize for setting a cookie to value xyz, or for calling function zyx().

Repeat until safe.. (Makes me think how bug bounties really are useful but not that useful for security).

I agree that safe eval and safe JSON parsing should be higher class citizens in the JS world. Just curious, is this (one of the reasons) why companies like Salesforce introduce an alternate language such as VisualForce, to have more control over safety? It would be nice to not have to force users to learn a new language to enable dynamic runtime features. I feel that it’s near impossible to outsmart all bad actors, but it would be nice to enable full user creativity by allowing access to an existing language.

If you really wanted to do this you could avoid a whole bunch of badness by spawning a worker, clearing out all the timer and networking APIs and just evaluate the script there.

Infinite loops etc could still happen but they would not significantly effect your page and the worker gets killed when the user navigates.

As far as their regex goes I’m not sure it actually prevents the wonders of [] based programming.

Python has ast.literal_eval built into the standard library, which is a pure Python lexer/parser/evaluator for Python syntax. So you don't have to write your own lexer and parser and so on. It's somewhat slower though, being written in pure Python.

Wouldn't doing `eval` in a service worker provide an even greater level of safety? Might even be enough to drop some of the character restrictions, if the use case was broader than the one here.