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 commit 3d1a14a (in
master) allows one to add a parser function to the sandbox for a more explicit inclusion (though it doesn't avoid anevalwith 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
preventEvaloption prevents use of filters entirely, avoiding the main concern, but also (unduly) restricting what features can be used.