it-swarm.com.de

Wann ist JavaScript's eval () nicht böse?

Ich schreibe einen JavaScript-Code, um vom Benutzer eingegebene Funktionen zu analysieren (für eine Tabellenkalkulationsfunktion). Nachdem ich die Formel I analysiert habe , könnte ich sie in JavaScript konvertieren und eval() ausführen, um das Ergebnis zu erhalten.

Ich habe jedoch immer darauf verzichtet, eval() zu verwenden, wenn ich es vermeiden kann, weil es böse ist (und zu Recht oder zu Unrecht habe ich immer gedacht, dass es in JavaScript noch böser ist, weil der Code so ist ausgewertet kann vom Benutzer geändert werden).

Also, wenn es in Ordnung ist, es zu benutzen?

250
Richard Turner

Ich möchte mir einen Moment Zeit nehmen, um auf die Prämisse Ihrer Frage einzugehen - diese eval () ist "evil". Das Wort "böse", wie es von Programmiersprachen verwendet wird, bedeutet normalerweise "gefährlich" oder genauer "mit einem einfach aussehenden Befehl viel Schaden anrichten können". Wann ist es in Ordnung, etwas Gefährliches einzusetzen? Wenn Sie die Gefahr kennen und die entsprechenden Vorsichtsmaßnahmen treffen.

Lassen Sie uns die Gefahren bei der Verwendung von eval () auf den Punkt bringen. Es gibt wahrscheinlich viele kleine versteckte Gefahren, genau wie alles andere, aber die beiden großen Risiken - der Grund, warum eval () als böse angesehen wird - sind Performance und Code-Injection.

  • Performance - eval () führt den Interpreter/Compiler aus. Wenn Ihr Code kompiliert ist, ist dies ein großer Erfolg, da Sie mitten in der Laufzeit einen möglicherweise schweren Compiler aufrufen müssen. JavaScript ist jedoch meistens immer noch eine interpretierte Sprache, was bedeutet, dass das Aufrufen von eval () im allgemeinen Fall keine große Leistungseinbuße darstellt (siehe aber meine spezifischen Bemerkungen unten).
  • Code-Injection - eval () führt möglicherweise eine Code-Zeichenfolge mit erhöhten Rechten aus. Beispielsweise möchte ein Programm, das als Administrator/root ausgeführt wird, niemals Benutzereingaben auswerten (), da diese Eingaben möglicherweise "rm -rf/etc/important-file" oder schlechter sein können. Auch hier hat JavaScript in einem Browser dieses Problem nicht, da das Programm ohnehin im eigenen Konto des Benutzers ausgeführt wird. Serverseitiges JavaScript könnte dieses Problem haben.

Weiter zu Ihrem speziellen Fall. Soweit ich weiß, generieren Sie die Zeichenfolgen selbst. Unter der Annahme, dass Sie nicht zulassen, dass eine Zeichenfolge wie "rm -rf something-important" generiert wird, besteht kein Risiko der Code-Injection (aber denken Sie daran, dass dies - sehr sehr schwer um dies im allgemeinen Fall sicherzustellen). Wenn Sie im Browser arbeiten, ist die Code-Injection meines Erachtens ein recht geringes Risiko.

Was die Leistung anbelangt, müssen Sie dies gegen die einfache Codierung abwägen. Ich bin der Meinung, dass Sie, wenn Sie die Formel analysieren, das Ergebnis auch während des Parsens berechnen können, anstatt einen anderen Parser (den in eval ()) auszuführen. Es kann jedoch einfacher sein, mit eval () zu programmieren, und der Leistungseinbruch ist wahrscheinlich nicht zu bemerken. Es sieht so aus, als ob eval () in diesem Fall nicht bösartiger ist als jede andere Funktion, die Ihnen möglicherweise Zeit sparen könnte.

253
user27476

eval() ist nicht böse. Wenn ja, ist es genauso schlimm, wie Reflexion, Datei-/Netzwerk-E/A, Threading und IPC in anderen Sprachen "schlimm" sind.

Wenn für Ihren Zweck, eval() schneller ist als die manuelle Interpretation oder Ihren Code einfacher oder klarer macht ... dann sollten Sie ihn verwenden. Wenn nicht, dann solltest du nicht. So einfach ist das.

72
Shog9

Wenn Sie der Quelle vertrauen.

Im Fall von JSON ist es mehr oder weniger schwierig, die Quelle zu manipulieren, da sie von einem Webserver stammt, den Sie steuern. Solange der JSON selbst keine Daten enthält, die ein Benutzer hochgeladen hat, besteht kein wesentlicher Nachteil bei der Verwendung von eval.

In allen anderen Fällen würde ich große Anstrengungen unternehmen, um sicherzustellen, dass vom Benutzer bereitgestellte Daten meinen Regeln entsprechen, bevor ich sie an eval () weitergebe.

55
Tomalak

Lassen Sie uns echte Leute bekommen:

  1. Jeder große Browser verfügt jetzt über eine integrierte Konsole, mit der Ihr angehender Hacker jede Funktion mit jedem Wert aufrufen kann - warum sollte er sich die Mühe machen, eine Auswertungsanweisung zu verwenden -, selbst wenn dies möglich wäre?

  2. Wenn es 0,2 Sekunden dauert, bis 2000 Zeilen JavaScript kompiliert sind, was ist mein Leistungsabfall, wenn ich vier Zeilen JSON auswerte?

Sogar Crockfords Erklärung für "Eval is Eval" ist schwach.

eval is Evil, Die eval-Funktion ist die am häufigsten missbrauchte Funktion von JavaScript. Vermeide es

Wie Crockford selbst sagen könnte: "Diese Art von Aussage kann zu irrationaler Neurose führen. Kaufen Sie sie nicht."

Das Verstehen von eval und das Wissen, wann es nützlich sein könnte, ist viel wichtiger. Zum Beispiel ist eval ein sinnvolles Tool zum Auswerten von Serverantworten, die von Ihrer Software generiert wurden.

Übrigens: Prototype.js ruft eval fünfmal direkt auf (einschließlich evalJSON () und evalResponse ()). jQuery verwendet es in parseJSON (über den Funktionskonstruktor).

23
plodder

Ich neige dazu, Crockfords Rat für eval() zu folgen und es insgesamt zu vermeiden. Selbst Möglichkeiten, die dies zu erfordern scheinen, gibt es nicht. Mit der Funktion setTimeout() können Sie beispielsweise eine Funktion übergeben, anstatt sie auszuwerten.

setTimeout(function() {
  alert('hi');
}, 1000);

Selbst wenn es sich um eine vertrauenswürdige Quelle handelt, verwende ich sie nicht, da der von JSON zurückgegebene Code möglicherweise verstümmelt ist und im besten Fall etwas Wonky tun könnte. im schlimmsten Fall etwas Schlimmes aussetzen.

18
swilliams

Beim Debuggen in Chrome (v28.0.1500.72) habe ich festgestellt, dass Variablen nicht an Abschlüsse gebunden sind, wenn sie nicht in einer verschachtelten Funktion verwendet werden, die den Abschluss erzeugt der JavaScript-Engine.

ABER : Wenn eval() in einer Funktion verwendet wird, die einen Abschluss verursacht, ALLE Die Variablen der äußeren Funktionen sind an den Abschluss gebunden, auch wenn sie überhaupt nicht verwendet werden. Wenn jemand die Zeit hat zu testen, ob dadurch Speicherlecks verursacht werden können, hinterlassen Sie mir bitte einen Kommentar.

Hier ist mein Testcode:

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is visible in debugger
            eval("1");
        })();
    }

    evalTest();
})();

(function () {
    var eval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();   // Variable "unused" is NOT visible in debugger
            var noval = eval;
            noval("1");
        })();
    }

    evalTest();
})();

(function () {
    var noval = function (arg) {
    };

    function evalTest() {
        var used = "used";
        var unused = "not used";

        (function () {
            used.toString();    // Variable "unused" is NOT visible in debugger
            noval("1");
        })();
    }

    evalTest();
})();

Ich möchte hier darauf hinweisen, dass eval () nicht unbedingt auf die native eval() -Funktion verweisen muss. Es hängt alles vom Namen der Funktion ab. Wenn Sie also die native eval() mit einem Aliasnamen aufrufen (sagen Sie var noval = eval; Und dann in einer inneren Funktion noval(expression);), kann die Auswertung von expression fehlschlagen wenn es sich um Variablen handelt, die Teil des Abschlusses sein sollten, dies aber nicht ist.

4
Benjamin

Ich habe gesehen, dass Leute befürworten, eval nicht zu verwenden, weil es evil ist, aber ich habe gesehen, dass dieselben Leute Function und setTimeout dynamisch verwenden, also verwenden sie eval under the hoods : D

Übrigens, wenn Ihre Sandbox nicht sicher genug ist (zum Beispiel, wenn Sie an einer Site arbeiten, die Code-Injection erlaubt), ist eval das letzte Ihrer Probleme. Die Grundregel der Sicherheit ist, dass all Eingaben böse sind, aber im Falle von JavaScript even kann JavaScript selbst böse sein, da Sie in JavaScript jede Funktion überschreiben können und Sie können einfach nicht sicher sein, ob Sie den echten Code verwenden. Wenn also ein bösartiger Code vor Ihnen startet, können Sie keiner integrierten JavaScript-Funktion vertrauen: D

Nun ist der Nachwort zu diesem Beitrag:

Wenn Sie WIRKLICH brauchen (80% der Zeit ist eval NICHT benötigt) und Sie sind sicher, was Sie tun, verwenden Sie einfach eval (oder eine bessere Funktion;)), closures und OOP decken 80/90% des Falls ab, in dem eval durch ersetzt werden kann Bei einer anderen Art von Logik handelt es sich bei dem Rest um dynamisch generierten Code (zum Beispiel, wenn Sie einen Interpreter schreiben) und, wie Sie bereits sagten, um die Evaluierung von JSON (hier können Sie die Crockford-sichere Evaluierung verwenden;)).

4
kentaromiura

Eval ist eine Ergänzung zur Kompilierung, die für das Templating des Codes verwendet wird. Mit Vorlage meine ich, dass Sie einen vereinfachten Vorlagengenerator schreiben, der nützlichen Vorlagencode generiert, der die Entwicklungsgeschwindigkeit erhöht.

Ich habe ein Framework geschrieben, in dem Entwickler EVAL nicht verwenden, aber sie unser Framework verwenden und das wiederum EVAL zum Generieren von Vorlagen verwenden muss.

Die Leistung von EVAL kann mithilfe der folgenden Methode gesteigert werden. Anstatt das Skript auszuführen, müssen Sie eine Funktion zurückgeben.

var a = eval("3 + 5");

Es sollte so organisiert sein

var f = eval("(function(a,b) { return a + b; })");

var a = f(3,5);

Caching f wird sicherlich die Geschwindigkeit verbessern.

Auch Chrome ermöglicht das Debuggen solcher Funktionen sehr einfach.

In Bezug auf die Sicherheit wird die Verwendung von eval oder not kaum einen Unterschied machen.

  1. Zunächst ruft der Browser das gesamte Skript in einer Sandbox auf.
  2. Jeder Code, der in EVAL böse ist, ist im Browser selbst böse. Der Angreifer oder jeder kann problemlos einen Skriptknoten in DOM einfügen und alles tun, wenn er/sie etwas auswerten kann. Die Nichtverwendung von EVAL macht keinen Unterschied .
  3. Es ist meistens eine schlechte serverseitige Sicherheit, die schädlich ist. Schlechte Cookies-Validierung oder schlechte ACL-Implementierung auf dem Server verursachen die meisten Angriffe.
  4. In Javas nativem Code gab es eine kürzlich aufgetretene Sicherheitsanfälligkeit (Java) usw.). JavaScript wurde und wird in einer Sandbox ausgeführt, während Applets so konzipiert wurden, dass sie außerhalb einer Sandbox mit Zertifikaten usw. ausgeführt werden zu Schwachstellen und vielen anderen Dingen.
  5. Das Schreiben von Code zum Imitieren eines Browsers ist nicht schwierig. Sie müssen lediglich eine HTTP-Anfrage mit Ihrer bevorzugten Benutzeragentenzeichenfolge an den Server senden. Alle Testtools machen sich sowieso über Browser lustig. Wenn ein Angreifer Ihnen Schaden zufügen möchte, ist EVAL der letzte Ausweg. Sie haben viele andere Möglichkeiten, um mit Ihrer serverseitigen Sicherheit umzugehen.
  6. Das Browser-DOM hat keinen Zugriff auf Dateien und keinen Benutzernamen. In der Tat kann nichts auf der Maschine, auf die eval zugreifen kann.

Wenn Ihre serverseitige Sicherheit solide genug ist, dass jeder von überall aus angreifen kann, sollten Sie sich keine Sorgen um EVAL machen. Wie bereits erwähnt, haben Angreifer unabhängig von Ihrem Browser viele Tools, die sie in Ihren Server hacken können, wenn EVAL nicht vorhanden wäre EVAL-Fähigkeit.

Eval eignet sich nur zum Generieren einiger Vorlagen, um komplexe Zeichenfolgen zu verarbeiten, die auf etwas basieren, das nicht im Voraus verwendet wird. Zum Beispiel werde ich bevorzugen

"FirstName + ' ' + LastName"

Im Gegensatz zu

"LastName + ' ' + FirstName"

Als mein Anzeigename, der aus einer Datenbank stammen kann und der nicht fest codiert ist.

4
Akash Kava
3

Die einzige Instanz, in der Sie eval () verwenden sollten, ist, wenn Sie dynamisches JS im laufenden Betrieb ausführen müssen. Ich spreche von JS, das Sie asynchron vom Server herunterladen ...

... und neunmal von zehn könnte man das leicht vermeiden, indem man umgestaltet.

2
Oli

Auf der Serverseite ist eval nützlich, wenn Sie mit externen Skripten wie sql oder influxdb oder mongo arbeiten. Während der Laufzeit kann eine benutzerdefinierte Überprüfung durchgeführt werden, ohne dass die Dienste erneut bereitgestellt werden müssen.

Zum Beispiel ein Leistungsservice mit folgenden Metadaten

{
  "568ff113-abcd-f123-84c5-871fe2007cf0": {
    "msg_enum": "quest/registration",
    "timely": "all_times",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/registration:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/registration\"}`"
  },
  "efdfb506-1234-abcd-9d4a-7d624c564332": {
    "msg_enum": "quest/daily-active",
    "timely": "daily",
    "scope": [
      "quest/daily-active"
    ],
    "query": "`SELECT COUNT(point) AS valid from \"${userId}/dump/quest/daily-active\" WHERE time >= '${today}' ${ENV.DAILY_OFFSET} LIMIT 1`",
    "validator": "valid > 0",
    "reward_external": "ewallet",
    "reward_external_payload": "`{\"token\": \"${token}\", \"userId\": \"${userId}\", \"amountIn\": 1, \"conversionType\": \"quest/daily-active:silver\", \"exchangeProvider\":\"provider/achievement\",\"exchangeType\":\"payment/quest/daily-active\"}`"
  }
}

Welche dann erlauben,

  • Direkte Einfügung von Objekten/Werten durch einen Literal-String in einen JSON-Code, nützlich zum Schablonieren von Texten

  • Kann als Vergleich verwendet werden, sagen wir, wir legen Regeln für die Validierung von Quests oder Ereignissen in CMS fest

Con davon:

  • Kann Fehler im Code sein und zu einer Aufschlüsselung des Dienstes führen, wenn er nicht vollständig getestet wurde.

  • Wenn ein Hacker ein Skript auf Ihrem System schreiben kann, sind Sie ziemlich durcheinander.

  • Eine Möglichkeit zur Überprüfung Ihres Skripts besteht darin, den Hash Ihrer Skripts an einem sicheren Ort aufzubewahren, damit Sie sie vor der Ausführung überprüfen können.

1
MichaelC

Endeffekt

Wenn Sie den Code, den Sie eval erstellt oder bereinigt haben, ist er niemals böse.

Etwas detaillierter

eval ist böse, wenn auf dem Server Eingaben von einem Client verwendet werden, der nicht vom Entwickler erstellt oder nicht bereinigt durch) war der Entwickler.

eval ist nicht böse, wenn es auf dem Client ausgeführt wird, auch wenn nicht vom Client gestaltete, nicht bereinigte Eingaben verwendet werden.

Offensichtlich sollten Sie die Eingabe immer bereinigen , um eine gewisse Kontrolle darüber zu haben, was Ihr Code verbraucht.

Argumentation

Der Client kann jeden beliebigen Code ausführen, selbst wenn der Entwickler ihn nicht codiert hat. Dies gilt nicht nur für , was ausgewertet wird, sondern auch für den Aufruf von eval selbst .

1
Steven Spungin

Ich denke, Fälle, in denen eine Bewertung gerechtfertigt ist, wären selten. Es ist wahrscheinlicher, dass Sie es verwenden, wenn Sie denken, es sei gerechtfertigt, als wenn Sie es verwenden, wenn es tatsächlich gerechtfertigt ist.

Die Sicherheitsprobleme sind die bekanntesten. Beachten Sie aber auch, dass JavaScript die JIT-Kompilierung verwendet und dies bei eval sehr schlecht funktioniert. Eval ist für den Compiler eine Art Blackbox, und JavaScript muss in der Lage sein, Code (in gewissem Maße) vorherzusagen, um Leistungsoptimierungen und Scoping sicher und korrekt anzuwenden. In einigen Fällen kann sich die Auswirkung auf die Leistung sogar auf anderen Code auswirken, der sich außerhalb der Evaluierungsphase befindet.

Wenn Sie mehr wissen möchten: https://github.com/getify/You-Dont-Know-JS/blob/master/scope%20%26%20closures/ch2.md#eval

1
Andre O

eval ist selten die richtige Wahl. Zwar gibt es zahlreiche Fälle, in denen Sie das Notwendige erreichen können, indem Sie ein Skript miteinander verketten und im laufenden Betrieb ausführen. In der Regel stehen Ihnen jedoch viel leistungsstärkere und wartbarere Techniken zur Verfügung: Assoziativ-Array-Notation (obj["prop"] ist das gleiche wie obj.prop), Verschlüsse, objektorientierte Techniken, funktionale Techniken - verwenden Sie sie stattdessen.

1
yfeldblum

Die Verwendung ist in Ordnung, wenn Sie die vollständige Kontrolle über den Code haben, der an die Funktion eval übergeben wird.

1
John Topley

Wann ist JavaScript's eval () nicht böse?

Ich versuche immer, davon abzuraten, eval zu verwenden . Fast immer ist eine sauberere und wartbarere Lösung verfügbar. Eval wird auch für JSON-Parsing nicht benötigt . Eval erhöht die Wartungshölle . Nicht ohne Grund wird es von Meistern wie Douglas Crockford missbilligt.

Aber ich habe ein Beispiel gefunden, wo es sollte sein verwendet wird:

Wenn Sie den Ausdruck übergeben müssen.

Ich habe zum Beispiel eine Funktion, die ein allgemeines google.maps.ImageMapType Objekt für mich, aber ich muss ihm das Rezept mitteilen, wie er die Kachel-URL aus den Parametern zoom und coord erstellen soll:

my_func({
    name: "OSM",
    tileURLexpr: '"http://tile.openstreetmap.org/"+b+"/"+a.x+"/"+a.y+".png"',
    ...
});

function my_func(opts)
{
    return new google.maps.ImageMapType({
        getTileUrl: function (coord, zoom) {
            var b = zoom;
            var a = coord;
            return eval(opts.tileURLexpr);
        },
        ....
    });
}
0
TMS

Wenn es wirklich gebraucht wird, ist eval nicht böse. Aber 99,9% der Verwendungen von eval, auf die ich stoße, werden nicht benötigt (ohne setTimeout-Zeug).

Für mich ist das Böse keine Leistung oder gar ein Sicherheitsproblem (na ja, indirekt ist es beides). All diese unnötigen Verwendungen von eval tragen zu einer Hölle der Wartung bei. Refactoring-Tools werden abgeworfen. Nach Code zu suchen ist schwierig. Unerwartete Auswirkungen dieser Auswertungen sind Legion.

0
PEZ

Codegenerierung. Ich habe kürzlich eine Bibliothek namens Hyperbars geschrieben, die die Lücke zwischen virtual-dom und handlebars schließt. Dazu wird eine Lenker-Vorlage analysiert und in Hyperskript konvertiert. Das Hyperskript wird zuerst als Zeichenfolge generiert und bevor es zurückgegeben wird, eval(), um es in ausführbaren Code umzuwandeln. Ich habe eval() in dieser besonderen Situation das genaue Gegenteil des Bösen gefunden.

Grundsätzlich aus

<div>
    {{#each names}}
        <span>{{this}}</span>
    {{/each}}
</div>

Dazu

(function (state) {
    var Runtime = Hyperbars.Runtime;
    var context = state;
    return h('div', {}, [Runtime.each(context['names'], context, function (context, parent, options) {
        return [h('span', {}, [options['@index'], context])]
    })])
}.bind({}))

Die Leistung von eval() ist auch in einer solchen Situation kein Problem, da Sie die generierte Zeichenfolge nur einmal interpretieren und die ausführbare Ausgabe dann mehrmals verwenden müssen.

Sie können sehen, wie die Code-Generierung erreicht wurde, wenn Sie neugierig sind hier .

0
Wikened

Mein Beispiel für die Verwendung von eval: Import.

Wie es normalerweise gemacht wird.

var components = require('components');
var Button = components.Button;
var ComboBox = components.ComboBox;
var CheckBox = components.CheckBox;
...
// That quickly gets very boring

Aber mit Hilfe von eval und einer kleinen Hilfsfunktion sieht es viel besser aus:

var components = require('components');
eval(importable('components', 'Button', 'ComboBox', 'CheckBox', ...));

importable sieht möglicherweise so aus (diese Version unterstützt das Importieren konkreter Elemente nicht).

function importable(path) {
    var name;
    var pkg = eval(path);
    var result = '\n';

    for (name in pkg) {
        result += 'if (name !== undefined) throw "import error: name already exists";\n'.replace(/name/g, name);
    }

    for (name in pkg) {
        result += 'var name = path.name;\n'.replace(/name/g, name).replace('path', path);
    }
    return result;
}
0
Yaroslav

Wenn möglich nur während des Testens. Beachten Sie auch, dass eval () viel langsamer ist als andere spezialisierte JSON-Evaluatoren.

0
Eric Wendelin

Es gibt keinen Grund, eval () nicht zu verwenden, solange Sie sicher sein können, dass die Quelle des Codes von Ihnen oder dem tatsächlichen Benutzer stammt. Obwohl er manipulieren kann, was in die eval () - Funktion gesendet wird, ist dies kein Sicherheitsproblem, da er den Quellcode der Website manipulieren und daher den JavaScript-Code selbst ändern kann.

Also ... wann soll eval () nicht verwendet werden? Eval () sollte nur dann nicht verwendet werden, wenn die Möglichkeit besteht, dass ein Dritter dies ändert. Wie das Abfangen der Verbindung zwischen dem Client und Ihrem Server (aber wenn das ein Problem ist, verwenden Sie HTTPS). Sie sollten eval () nicht verwenden, um Code zu analysieren, der von anderen wie in einem Forum geschrieben wurde.

0
Georg Schölly

Was das Client-Skript angeht, ist das Thema Sicherheit meines Erachtens ein strittiger Punkt. Alles, was in den Browser geladen wird, unterliegt Manipulationen und sollte als solche behandelt werden. Die Verwendung einer eval () -Anweisung birgt kein Risiko, wenn JavaScript-Code auf viel einfachere Weise ausgeführt und/oder Objekte im DOM bearbeitet werden können, z. B. die URL-Leiste in Ihrem Browser.

javascript:alert("hello");

Wenn jemand sein DOM manipulieren will, sage ich wegschwingen. Die Sicherheit, um Angriffe jeglicher Art zu verhindern, sollte immer in der Verantwortung der Serveranwendung liegen.

Aus pragmatischer Sicht hat die Verwendung von eval () keinen Vorteil in Situationen, in denen etwas anders gemacht werden kann. Es gibt jedoch bestimmte Fälle, in denen eine Bewertung verwendet werden MUSS. Wenn ja, kann dies definitiv ohne die Gefahr der Vergrößerung der Seite geschehen.

<html>
    <body>
        <textarea id="output"></textarea><br/>
        <input type="text" id="input" />
        <button id="button" onclick="execute()">eval</button>

        <script type="text/javascript">
            var execute = function(){
                var inputEl = document.getElementById('input');
                var toEval = inputEl.value;
                var outputEl = document.getElementById('output');
                var output = "";

                try {
                    output = eval(toEval);
                }
                catch(err){
                    for(var key in err){
                        output += key + ": " + err[key] + "\r\n";
                    }
                }
                outputEl.value = output;
            }
        </script>
    <body>
</html>
0
SawedUp

Eval ist nützlich für die Codegenerierung, wenn Sie keine Makros haben.

Wenn Sie beispielsweise einen Brainfuck - Compiler schreiben, möchten Sie wahrscheinlich eine Funktion erstellen, die die Befehlssequenz als Zeichenfolge ausführt, und sie auswerten, um eine Funktion zurückzugeben.

0
Erik Haliewicz

Meiner Meinung nach ist eval eine sehr leistungsstarke Funktion für clientseitige Webanwendungen und sicher ... So sicher wie JavaScript, was nicht der Fall ist. :-) Die Sicherheitsprobleme sind im Wesentlichen ein serverseitiges Problem, da Sie jetzt mit einem Tool wie Firebug jede JavaScript-Anwendung angreifen können.

0
maza