Czy istnieje sposób sprawdzenia, czy natywna funkcja JavaScript została poprawiona przez małpy?

Question

Na przykład wczytałem skrypt na jakiejś stronie i chciałbym wiedzieć, czy JSON.parse/stringify nie został poprawiony przez małpy.

Zauważyłem, że jeśli mogę użyć toString funkcję w Chrome/FF, JSON.stringify.toString, potem wrócę:

function stringify() { 
    [native code] 
} 

Moje pytanie brzmi, czy myślisz, że jest to dobry sposób, aby sprawdzić, czy funkcja była małpa załatana? Chciałbym usłyszeć o każdym innym podejściu do tego problemu.

Answer 1

Tak, jest to jedyny praktyczny sposób sprawdzenia, czy natywna funkcja nie została nadpisana czy nie.

const isNative = fn => !!fn.toString().match(/\[native code\]/) 

console.log(isNative(JSON.stringify)); 

bardziej niezawodne rozwiązanie może wykorzystywać Function.prototype.toString() zamiast bezpośredniego połączenia z fn.toString(), ale obie są monkeypatchable również. Radość JavaScript :)

Answer 2

Można by łatwo fałszywy JSON.stringify.toString

JSON.stringify = function() {} 
JSON.stringify.toString = function() {return 'ha-ha'} 

console.log(JSON.stringify); //ha-ha 

Nieco bardziej wytrzymałe sposób byłoby użyć Function.prototype.toString

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

Ale naprawdę źle monkeypatcher mógłby załatać Function.prototype.toString jak dobrze :)

Answer 3

Specyfikacja (http://www.ecma-international.org/ecma-262/7.0/index.html#sec-function.prototype.tostring) nie określa dokładnego ciągu znaków zwracanego dla wbudowanego functi na:

19.2.3.5 Function.prototype.toString

Gdy metoda toString nazywany jest na func obiektu, następujące kroki podejmowane są:

Jeśli func jest oprawionego Funkcja egzotyczny przedmiot , następnie Zwróć implementację zależną od implementacji Przedstawienie kodu źródłowego funkcji func. Reprezentacja musi być zgodna z poniższymi regułami. Jest zależne od implementacji, czy reprezentacja zawiera powiązaną informację o funkcji lub informacje o funkcji docelowej. Jeśli Typ (func) jest obiektem i jest wbudowanym obiektem funkcji lub ma wewnętrzne gniazdo [[ECMAScriptCode]], a następnie zwraca zależną od implementacji łańcuchową reprezentację kodu źródłowego func. Reprezentacja musi być zgodna z poniższymi regułami. Zgłoszenie wyjątku TypeError . toString reprezentacyjne Wymagania:

reprezentacja ciąg musi mieć składnię FunctionDeclaration, FunctionExpression, GeneratorDeclaration, GeneratorExpression, ClassDeclaration, ClassExpression, ArrowFunction, MethodDefinition lub GeneratorMethod zależności od rzeczywistych cech obiektu. Używanie i umieszczanie białych znaków, terminatorów linii i średników w ciągu znaków reprezentacji jest zależne od implementacji od .Jeśli obiekt został zdefiniowany przy użyciu kodu ECMAScript , a zwrócona reprezentacja łańcuchów nie ma formy MethodDefinition lub GeneratorMethod, wówczas reprezentacja musi być taka, że ​​jeśli łańcuch jest oceniany, użycie eval w kontekście leksykalnym , który jest równoważny kontekst leksykalny użyty do stworzenia oryginalnego obiektu , spowoduje powstanie nowego funkcjonalnie równoważnego obiektu. W tym przypadku zwracany kod źródłowy nie może swobodnie wymieniać dowolnych zmiennych , które nie były swobodnie wymieniane przez kod źródłowy oryginalnej funkcji, , nawet jeśli te "dodatkowe" nazwy były pierwotnie w zakresie. Jeśli implementacja nie może wytworzyć łańcucha kodu źródłowego, który spełnia tych kryteriów, to musi zwrócić ciąg, dla którego eval wyrzuci wyjątek SyntaxError.

Sprawdzanie pod kątem [Native Code] może, ale nie musi działać w zależności od tłumacza. Ponadto implementacja może również zaimplementować wbudowane funkcje jako normalny kod javascript.

Tak więc w odpowiedzi na twoje pytanie nie można ustalić, czy jest określony w JavaScript, czy wbudowana funkcja została poprawiona małpkowo.

To powiedziawszy, wygląda na to, że Chrome i Firefox zwracają ciąg znaków [Native Code] pod warunkiem sprawdzenia innych implementacji, które mogą być rozwiązaniem pragmatycznym.