You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
brettz9
changed the title
For filtering, when requiring arbitrary JavaScript, eval in sandbox, and otherwise avoid eval()
For filtering, when arbitrary JavaScript is whitelisted, eval in sandbox; otherwise avoid eval()
Dec 13, 2015
brettz9
changed the title
For filtering, when arbitrary JavaScript is whitelisted, eval in sandbox; otherwise avoid eval()
FEATURE: For filtering, when arbitrary JavaScript is whitelisted, eval in sandbox; otherwise avoid eval()
Dec 13, 2015
brettz9
changed the title
FEATURE: For filtering, when arbitrary JavaScript is whitelisted, eval in sandbox; otherwise avoid eval()
For filtering, when arbitrary JavaScript is whitelisted, eval in sandbox; otherwise avoid eval()
Dec 14, 2015
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.
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 aneval
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.The text was updated successfully, but these errors were encountered: