Is there a way to check if a monkey has inherited a built-in Javascript function?

For example, I uploaded a script to a website, and I would like to know if the JSON.parse / stringify file has been fixed.

I noticed that if I use toString for a function in Chrome / FF, JSON.stringify.toString , I will return:

 function stringify() { [native code] } 

My question is: do you think this is a good way to check if a function has been neutralized by a monkey? I would also like to hear about any other approaches to this problem.

+5
source share
3 answers

Yes, this is the only practical way to check if a native function has been redefined or not.

 const isNative = fn => !!fn.toString().match(/\[native code\]/) console.log(isNative(JSON.stringify)); 

A more robust solution might use Function.prototype.toString() instead of calling fn.toString() directly, but both of them can also be replaced with monkey. Joy of JavaScript :)

+4
source

You can easily fake JSON.stringify.toString

 JSON.stringify = function() {} JSON.stringify.toString = function() {return 'ha-ha'} console.log(JSON.stringify); //ha-ha 

An even more reliable way would be to use Function.prototype.toString

 Function.prototype.toString.call(JSON.stringify) 

But a really bad spider monkey can patch Function.prototype.toString :)

+4
source

The specification ( http://www.ecma-international.org/ecma-262/7.0/index.html#sec-function.prototype.tostring ) does not indicate the exact string returned by the built-in function:

19.2.3.5 .prototype.toString Function

When the toString method is called for the func function, the following steps are taken:

If func is an exotic Bound Function object, then Return a is implementation dependent . Func string representation of the source code. The submission must comply with the rules below. this implementation depends on whether the view includes information about the function or information about the objective function. If the Type (func) is an Object and is either a built-in functional object or has an internal [[ECMAScriptCode]] slot, then return an implementation-dependent representation of the source code for the func string. The submission must comply with the rules below. Throw a TypeError exception. ToString view requirements:

The string representation must have the syntax FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, ClassDeclaration, ClassExpression, ArrowFunction, MethodDefinition or GeneratorMethod depending on the actual characteristics of the object. The use and placement of spaces, line delimiters, and semicolons in the String view are implementation dependent. If the object was defined using ECMAScript code and the return representation of the string is not in the form of MethodDefinition or GeneratorMethod, then the representation should be such that if the string is evaluated using eval in the lexical context, which is equivalent to the lexical context used to create the original object, this will create new functionally equivalent object. In this case, the returned source code should not freely mention variables that were not freely mentioned by the source function of the source code, even if these "additional" names were originally in scope. If the implementation cannot create a line of source code that meets these criteria then it must return a line for which eval will throw a SyntaxError exception.

Thus, checking for [Native Code] may or may not work depending on the interpreter. In addition, an implementation may well implement inline functions like regular JavaScript code.

So, in answer to your question, you cannot determine if Javascript is in the indicated way, whether the built-in function was processed by a monkey.

Chrome and Firefox are said to return the [Native Code] string to be checked for other implementations, which might be a pragmatic solution.

+3
source

All Articles