41 ms·

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

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.

__s 8y ago
The problem is that you need to sandbox prototypes et al https://en.wikipedia.org/wiki/JSFuck https://en.wikipedia.org/wiki/JSFuck https://stackoverflow.com/questions/2669690/why-does-google-prepend-while1-to-their-json-responses https://stackoverflow.com/questions/2669690/why-does-google-...
- cormacrelf 8y ago
  I can't believe nobody else pointed out JSFuck. Try the converter at http://www.jsfuck.com/ http://www.jsfuck.com/ -- or browse the esolang entry: https://esolangs.org/wiki/JSFuck https://esolangs.org/wiki/JSFuck Spoiler: it can do everything normal JS can. Just because it uses 20,000 characters to do a simple if statement doesn't mean your eval is 'safe'.
abecedarius 8y ago
Right. Access to the environment is the dangerous part, not the eval function. There's a proposal to tame the JS global environment along those lines: https://github.com/tc39/proposal-frozen-realms https://github.com/tc39/proposal-frozen-realms Note however that the threat model here does not include denial of service. You have to address that at another level like OS processes or E vats.