fix($parse): function call context should be safe #4417
Conversation
|
Oh Chirayu! Nice to see you sending PRs again! :) |
| @@ -754,6 +754,7 @@ Parser.prototype = { | |||
| } | |||
| var fnPtr = fn(scope, locals, context) || noop; | |||
|
|
|||
| ensureSafeObject(context, parser.text); | |||
| ensureSafeObject(fnPtr, parser.text); | |||
There was a problem hiding this comment.
Do we need to check the fnPtr?
There was a problem hiding this comment.
Yes, to check for the Function constructor.
|
LGTM. I would change the commit msg (something like |
|
@IgorMinar – I think it's a good idea to check the return value. If someone can get a window/document object returned from a function – even if they can't use it directly in a function call, they could pass it to another function that invokes someone on it, etc. While we could remove it, I prefer keeping it considering the overhead of the function call path. |
|
lgtm |
|
@chirayuk This sandboxing technique is not perfect and doesn't aim to be. The goal is to prevent exploits against the expression language, but not to prevent exploits that were enabled by exposing sensitive JavaScript or browser apis on Scope. Exposing such objects on a Scope is never a good practice and therefore we are not even trying to protect against interaction with an object explicitly exposed in this way. |
No description provided.