For filtering, when arbitrary JavaScript is whitelisted, eval in sandbox; otherwise avoid eval()

[brettz9]

The commit 3d1a14a (in master) allows one to add a parser function to the sandbox for a more explicit inclusion (though it doesn't avoid an eval with access to global variables). I think should become the required approach once we may move to evaluating in a true sandbox, using something perhaps like this: http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/ .

I would also like to see inclusion of something like PR #4 to avoid the need for eval() in those cases where filters are used but where arbitrary JavaScript is not needed. I also think this ought to become the new default for security reasons.

Note that the new preventEval option prevents use of filters entirely, avoiding the main concern, but also (unduly) restricting what features can be used.

[diegodlh]

Has there been any progress regarding this? I'm developing a library that takes user input as JSONPath and I'd rather not have to disable filters altogether.

I wasn't sure what the implications of evaluating whatever user input were, until I came up with this simple example (that may help others who were not sure too):

This website uses jsonpath-plus: https://jsonpath.com/. If, for example, you use a JSONPath expression that includes window.close(), the window will in fact close! For instance, $.phoneNumbers[(window.close)].type.

A similar library, @dchester's jsonpath, seems to have solved this. See here.

[brettz9]

This library is not under active development. Well-documented PR's would be welcome, but it is currently not being actively maintained.