it-swarm.com.de

Warum werden eval-ähnliche Merkmale im Gegensatz zu anderen möglicherweise schädlichen Merkmalen als böse angesehen?

Die meisten modernen Sprachen (die irgendwie interpretiert werden) haben eine Art eval Funktion. Eine solche Funktion führt einen beliebigen Sprachcode aus, der die meiste Zeit als Hauptargument als Zeichenfolge übergeben wird (verschiedene Sprachen können der Bewertungsfunktion weitere Funktionen hinzufügen).

Ich verstehe, dass Benutzer diese Funktion nicht ausführen dürfen (bearbeiten dh direkt oder indirekt beliebige Eingaben von einem beliebigen Benutzer vornehmen, die an eval übergeben werden sollen), insbesondere mit serverseitiger Software. da sie den Prozess zwingen könnten, schädlichen Code auszuführen. Auf diese Weise fordern uns Tutorials und Communitys auf, nicht eval zu verwenden. Es gibt jedoch viele Male, in denen eval nützlich ist und verwendet wird:

  • Benutzerdefinierte Zugriffsregeln auf Softwareelemente (IIRC OpenERP hat ein Objekt ir.rule, das dynamischen python Code) verwenden kann.
  • Benutzerdefinierte Berechnungen und/oder Kriterien (OpenERP verfügt über solche Felder, um benutzerdefinierte Codeberechnungen zu ermöglichen).
  • Parser für OpenERP-Berichte (ja, ich weiß, ich mache dich mit OpenERP-Sachen fertig ... aber es ist das Hauptbeispiel, das ich habe).
  • Codierung von Zaubereffekten in einigen RPG-Spielen.

Sie haben also eine gute Verwendung, solange sie richtig verwendet werden. Der Hauptvorteil besteht darin, dass Administratoren mit dieser Funktion benutzerdefinierten Code schreiben können, ohne weitere Dateien erstellen und einschließen zu müssen (obwohl die meisten Frameworks, die eval-Funktionen verwenden, auch die Möglichkeit haben, eine Datei, ein Modul, ein Paket usw. anzugeben, aus dem gelesen werden soll).

Eval ist jedoch in der Populärkultur böse. Dinge wie das Eindringen in Ihr System kommen Ihnen in den Sinn.

Es gibt jedoch andere Funktionen, die schädlich sein können, wenn Benutzer irgendwie darauf zugreifen: Verknüpfung aufheben, lesen, schreiben (Dateisemantik), Speicherzuordnung und Zeigerarithmetik, Zugriff auf Datenbankmodelle (auch wenn SQL-injizierbare Fälle nicht berücksichtigt werden).

Also im Grunde die meiste Zeit, wenn any Code nicht richtig geschrieben ist oder nicht beobachtet richtig (Ressourcen, Benutzer, Umgebungen, ...), die Code ist böse und kann sogar zu wirtschaftlichen Auswirkungen führen.

Aber es gibt etwas Besonderes mit eval Funktionen (unabhängig von der Sprache).

Frage: Gibt es eine historische Tatsache dafür, dass diese Angst Teil der Populärkultur wird, anstatt den anderen möglicherweise gefährlichen Merkmalen die gleiche Aufmerksamkeit zu schenken?

51
Luis Masuelli

Eine eval -Funktion an sich ist nicht böse, und es gibt einen subtilen Punkt, von dem ich nicht glaube, dass Sie ihn machen:

Es ist schlecht, einem Programm zu erlauben, beliebige Benutzereingaben auszuführen

Ich habe Code geschrieben, der eine Funktion vom Typ eval verwendet hat, und sie war sicher: Das Programm und die Parameter waren fest codiert. Manchmal gibt es keine Sprach- oder Bibliotheksfunktion, um das zu tun, was das Programm benötigt, und das Ausführen eines Shell-Befehls ist der kurze Weg. "Ich muss das Codieren in ein paar Stunden beenden, aber das Schreiben von Java/.NET/PHP/was auch immer Code dauert zwei Tage. Oder ich kann es in fünf Minuten eval."

Sobald Sie Benutzern erlauben, alles auszuführen, was sie wollen, selbst wenn sie durch Benutzerrechte oder hinter einem "sicheren" Bildschirm gesperrt sind, erstellen Sie Angriffsvektoren. Jede Woche hat ein zufälliges CMS, eine Blogging-Software usw. eine Sicherheitslücke, durch die ein Angreifer eine solche Lücke ausnutzen kann. Sie verlassen sich auf den gesamten Software-Stack, um den Zugriff auf eine Funktion zu schützen, mit der rm -rf / oder etwas anderes Katastrophales (Hinweis: Dieser Befehl ist wahrscheinlich nicht erfolgreich, schlägt jedoch fehl , nachdem ein wenig Schaden verursacht hat).

Gibt es eine historische Tatsache dafür, dass diese Angst Teil der Populärkultur wird, anstatt den anderen möglicherweise gefährlichen Merkmalen die gleiche Aufmerksamkeit zu widmen?

Ja, es gibt einen historischen Präzedenzfall. Aufgrund der zahlreichen Fehler, die im Laufe der Jahre in verschiedenen Softwareprogrammen behoben wurden, mit denen Angreifer aus der Ferne beliebigen Code ausführen können, ist die Idee von eval größtenteils in Ungnade gefallen. Moderne Sprachen und Bibliotheken verfügen über umfangreiche Funktionen, die eval weniger wichtig machen, und dies ist kein Zufall. Dies erleichtert die Verwendung von Funktionen und verringert das Risiko eines Exploits.

Viele potenziell unsichere Funktionen in gängigen Sprachen wurden viel beachtet. Ob man mehr Aufmerksamkeit erhält, ist in erster Linie Ansichtssache, aber die eval -Funktionen haben sicherlich ein nachweisbares Sicherheitsproblem, das leicht zu verstehen ist . Zum einen ermöglichen sie die Ausführung von Betriebssystembefehlen, einschließlich integrierter Shell-Programme und externer Programme, die Standard sind (z. B. rm oder del). Zweitens kann ein Angreifer in Kombination mit anderen Exploits möglicherweise seine eigene ausführbare Datei oder sein eigenes Shell-Skript hochladen und dann über Ihre Software ausführen, sodass fast alles passieren kann (nichts davon ist gut).

Dies ist ein schwieriges Problem. Software ist komplex und ein Software-Stack (z. B. LAMPE ) besteht aus mehreren Teilen von Software, die auf komplexe Weise miteinander interagieren. Seien Sie vorsichtig, wie Sie solche Sprachfunktionen verwenden, und erlauben Sie Benutzern niemals, beliebige Befehle auszuführen.

76
user22815

Ein Teil davon ist einfach, dass Nuancen schwer sind. Es ist einfach zu sagen, dass Sie niemals goto, öffentliche Felder, String-Interpolation für SQL-Abfragen oder eval verwenden. Diese Aussagen sollten nicht wirklich so verstanden werden, dass es unter keinen Umständen einen Grund gibt, sie zu verwenden. Es ist jedoch eine gute Idee, sie als Faustregel zu vermeiden.

Eval wird stark entmutigt, da es mehrere häufig auftretende Probleme kombiniert.

Erstens ist es anfällig für Injektionsattacken. Hier ist es insofern wie bei der SQL-Injection, als wenn benutzergesteuerte Daten in den Code eingefügt werden, es leicht ist, versehentlich das Einfügen von beliebigem Code zuzulassen.

Zweitens neigen Anfänger dazu, eval zu verwenden, um schlecht strukturierten Code zu umgehen. Ein Anfänger-Codierer könnte Code schreiben, der wie folgt aussieht:

x0 = "hello"
x1 = "world"
x2 = "how"
x3 = "are"
x4 = "you?"
for index in range(5):
   print eval("x" + index)

Dies funktioniert, ist aber wirklich der falsche Weg, um dieses Problem zu lösen. Offensichtlich wäre die Verwendung einer Liste viel besser.

Drittens ist die Bewertung in der Regel ineffizient. Es wird viel Aufwand betrieben, um die Implementierung unserer Programmiersprachen zu beschleunigen. Es ist jedoch schwierig, die Bewertung zu beschleunigen, und die Verwendung wirkt sich normalerweise nachteilig auf Ihre Leistung aus.

Eval ist also nicht böse. Wir könnten sagen, dass Eval böse ist, denn es ist eine eingängige Art, es auszudrücken. Jeder Anfänger sollte sich unbedingt von eval fernhalten, denn was auch immer er tun möchte, eval ist mit ziemlicher Sicherheit die falsche Lösung. Für bestimmte fortgeschrittene Anwendungsfälle ist eval sinnvoll, und Sie sollten es verwenden, aber achten Sie natürlich auf die Fallstricke.

38
Winston Ewert

Es läuft darauf hinaus, dass "willkürliche Codeausführung" Tech-Talk für "in der Lage ist, alles zu tun" ist. Wenn jemand in der Lage ist, die Ausführung von willkürlichem Code in Ihrem Code auszunutzen, ist dies buchstäblich die schlimmste Sicherheitslücke, die möglich ist, weil dies bedeutet er kann alles tun, was für Ihr System möglich ist.

"Andere möglicherweise schädliche Fehler" können durchaus Grenzen haben, was bedeutet, dass sie per Definition weniger Schaden anrichten können als eine willkürliche Codeausführung, die ausgenutzt wird.

20
Mason Wheeler

Es gibt einen praktischen und einen theoretischen Grund.

Der praktische Grund ist, dass wir beobachten, dass es häufig Probleme verursacht. Es ist selten, dass eine Bewertung zu einer guten Lösung führt, und es führt häufig zu einer schlechten Lösung, bei der Sie am Ende eine bessere Lösung hätten, wenn Sie so getan hätten, als gäbe es keine Bewertung und würden das Problem anders angehen. Der vereinfachte Rat besteht also darin, ihn zu ignorieren. Wenn Sie einen Fall finden, in dem Sie den vereinfachten Rat ignorieren möchten, hoffen wir, dass Sie ihn ausreichend durchdacht haben, um zu verstehen, warum der vereinfachte Rat nicht anwendbar und üblich ist Fallstricke betreffen Sie nicht.

Der theoretischere Grund ist, dass wenn es schwierig ist, guten Code zu schreiben, es noch schwieriger ist, Code zu schreiben, der guten Code schreibt. Unabhängig davon, ob Sie eval verwenden, SQL-Anweisungen durch Zusammenkleben von Zeichenfolgen generieren oder einen JIT-Compiler schreiben, ist das, was Sie versuchen, oft schwieriger als erwartet. Das Potenzial für die Injektion von bösartigem Code ist ein großer Teil des Problems. Abgesehen davon ist es im Allgemeinen schwieriger, die Richtigkeit Ihres Codes zu ermitteln, wenn Ihr Code erst zur Laufzeit vorhanden ist. Der vereinfachte Rat ist also, die Dinge für sich selbst einfacher zu halten: "Verwenden Sie parametrisierte SQL-Abfragen", "Verwenden Sie keine Bewertung".

Beispiel für Zaubereffekte: Es ist eine Sache, einen Lua-Compiler oder -Interpreter (oder was auch immer) in Ihr Spiel zu integrieren, damit Spieleentwickler eine einfachere Sprache als C++ (oder was auch immer) zur Beschreibung von Zaubereffekten verwenden können. Die meisten "Probleme der Bewertung" treten nicht auf, wenn Sie nur Code auswerten, der geschrieben und getestet und im Spiel oder in DLC oder What-Have-You enthalten ist. Das ist nur das Mischen von Sprachen. Die großen Probleme treten auf, wenn Sie versuchen, Lua (oder C++ - oder SQL- oder Shell-Befehle oder was auch immer) im laufenden Betrieb zu generieren und durcheinander zu bringen.

15
Steve Jessop

Nein, es gibt keine offensichtliche historische Tatsache.

Die Übel des Eval sind von Anfang an deutlich zu sehen. Andere Merkmale sind leicht gefährlich. Leute können Daten löschen. Menschen können Daten sehen, die sie nicht sehen sollten. Leute können Daten schreiben, die sie nicht sollten. Und sie können die meisten dieser Dinge nur tun, wenn Sie es irgendwie vermasseln und Benutzereingaben nicht validieren.

Mit eval können sie das Fünfeck hacken und es so aussehen lassen, wie Sie es getan haben. Sie können Ihre Tastenanschläge überprüfen, um Ihre Passwörter zu erhalten. Unter der Annahme einer vollständigen Turing-Sprache können sie buchstäblich alles tun, was Ihr Computer kann.

Und Sie können die Eingabe nicht validieren. Es ist eine beliebige Freiformzeichenfolge. Die einzige Möglichkeit zur Validierung besteht darin, eine Parser- und Code-Analyse-Engine für die betreffende Sprache zu erstellen. Viel Glück damit.

11
Telastyn

Ich denke, es läuft auf folgende Aspekte hinaus:

  • Notwendigkeit
  • (Bewachte) Verwendung
  • Zugriff
  • Überprüfbarkeit
  • Mehrstufige Angriffe

Notwendigkeit

Hallo, ich habe dieses extrem coole Bildbearbeitungswerkzeug geschrieben (erhältlich für 0,02 USD). Nachdem Sie das Bild geöffnet haben, können Sie eine Vielzahl von Filtern über Ihr Bild übertragen. Sie können sogar einige selbst mit Python (das Programm, in dem ich die Anwendung geschrieben habe) skripten. Ich verwende einfach eval für Ihre Eingabe und vertraue darauf, dass Sie ein seriöser Mensch sind Benutzer.

(später)

Danke, dass Sie es gekauft haben. Wie Sie sehen, funktioniert es genau so, wie ich es versprochen habe. Oh, du willst ein Bild öffnen? Nein, das kannst du nicht. Ich werde die read -Methode nicht verwenden, da sie etwas unsicher ist. Sparen? Nein, ich werde write nicht verwenden.

Ich versuche zu sagen: Sie benötigen Lesen/Schreiben für fast die grundlegenden Werkzeuge. Gleiches gilt für das Speichern der Highscores Ihres ach so tollen Spiels.

Ohne Lesen/Schreiben ist Ihr Bildeditor unbrauchbar. Ohne eval? Ich werde dir ein benutzerdefiniertes Plugin dafür schreiben!

(Bewachte) Verwendung

Viele Methoden können möglicherweise gefährlich sein. Wie zum Beispiel die read und write. Ein häufiges Beispiel ist ein Webdienst, mit dem Sie Bilder aus einem bestimmten Verzeichnis lesen können, indem Sie den Namen angeben. Der 'Name' kann jedoch tatsächlich ein beliebiger gültiger (relativer) Pfad auf dem System sein, sodass Sie alle Dateien lesen können, auf die der Webdienst Zugriff hat, nicht nur die Bilder. Der Missbrauch dieses einfachen Beispiels wird als "Pfaddurchquerung" bezeichnet. Wenn Ihre App die Pfadüberquerung zulässt, ist dies schlecht. Ein read ohne Verteidigung gegen Pfadüberquerung kann auch als böse bezeichnet werden.

In anderen Fällen befindet sich die Zeichenfolge für read jedoch vollständig unter der Kontrolle des Programmierers (möglicherweise fest codiert?). In diesem Fall ist es kaum böse, read zu verwenden.

Zugriff

Nun ein weiteres einfaches Beispiel mit eval.

Irgendwo in Ihrer Web-App möchten Sie dynamische Inhalte. Sie werden den Administratoren erlauben, einen Code einzugeben, der ausführbar ist. Da die Administratoren vertrauenswürdige Benutzer sind, kann dies theoretisch in Ordnung sein. Stellen Sie nur sicher, dass Sie keinen Code ausführen, der von Nicht-Administratoren gesendet wurde, und alles in Ordnung.

(Das heißt, bis Sie diesen netten Administrator entlassen haben, aber vergessen haben, seinen Zugriff zu widerrufen. Jetzt wird Ihre Web-App verworfen.).

Überprüfbarkeit.

Ein weiterer wichtiger Aspekt ist meiner Meinung nach, wie einfach es ist, Benutzereingaben zu überprüfen.

Benutzereingaben in einem Leseanruf verwenden? Stellen Sie einfach (sehr) sicher, dass die Eingabe für den Leseaufruf nichts Bösartiges enthält. Normalisieren Sie den Pfad und überprüfen Sie, ob sich die geöffnete Datei in Ihrem Medienverzeichnis befindet. Das ist sicher.

Benutzereingabe bei einem Schreibanruf? Gleich!

SQL-Injektion? Entfliehen Sie einfach oder verwenden Sie parametrisierte Abfragen, und Sie sind sicher.

Eval? Wie überprüfen Sie die Eingabe, die für den Aufruf von eval verwendet wird? Sie können sehr hart arbeiten, aber es ist wirklich sehr, sehr schwer (wenn nicht unmöglich), es sicher arbeiten zu lassen.

Mehrstufige Angriffe

Jedes Mal, wenn Sie Benutzereingaben verwenden, müssen Sie die Vorteile der Verwendung gegen die Gefahren abwägen. Schützen Sie die Nutzung so weit wie möglich.

Betrachten Sie noch einmal das evalable-Zeug im Admin-Beispiel. Ich habe dir gesagt, dass das irgendwie in Ordnung ist.

Bedenken Sie nun, dass es in Ihrer Web-App tatsächlich einen Ort gibt, an dem Sie vergessen haben, Benutzerinhalten (HTML, XSS) zu entkommen. Das ist eine geringere Straftat als eine vom Benutzer zugängliche Bewertung. Mithilfe des nicht entkoppelten Benutzerinhalts kann ein Benutzer jedoch den Webbrowser eines Administrators übernehmen und während der Administratorsitzung einen evalable-Blob hinzufügen, der erneut den vollständigen Systemzugriff ermöglicht.

(Der gleiche mehrstufige Angriff kann mit SQL-Injection anstelle von XSS oder mit beliebigen Dateischreibvorgängen durchgeführt werden, die ausführbaren Code ersetzen, anstatt eval zu verwenden.)

6

Damit diese Funktion überhaupt funktioniert, muss eine Reflexionsebene vorhanden sein, die den vollständigen Zugriff auf den internen Status des gesamten Programms ermöglicht.

Für interpretierte Sprachen kann ich einfach den Interpreter-Status verwenden, was einfach ist, aber in Kombination mit JIT-Compilern die Komplexität immer noch erheblich erhöht.

Ohne eval kann der JIT-Compiler häufig nachweisen, dass auf die lokalen Daten eines Threads von keinem anderen Code aus zugegriffen wird. Daher ist es durchaus akzeptabel, Zugriffe neu zu ordnen, Sperren wegzulassen und häufig verwendete Daten für längere Zeit zwischenzuspeichern. Wenn ein anderer Thread eine eval -Anweisung ausführt, muss möglicherweise der laufende kompilierte JIT-Code damit synchronisiert werden. Daher benötigt der von JIT generierte Code plötzlich einen Fallback-Mechanismus, der innerhalb eines vernünftigen Zeitrahmens zur nicht optimierten Ausführung zurückkehrt.

Diese Art von Code weist in der Regel viele subtile, schwer zu reproduzierende Fehler auf und schränkt gleichzeitig die Optimierung im JIT-Compiler ein.

Bei kompilierten Sprachen ist der Kompromiss noch schlimmer: Die meisten Optimierungen sind verboten, und ich muss umfangreiche Symbolinformationen und einen Interpreter bereithalten, sodass sich die zusätzliche Flexibilität im Allgemeinen nicht lohnt - es ist oft einfacher, eine Schnittstelle zu einigen internen zu definieren Strukturen, z durch Erteilen eines Skripts Ansicht und Controller gleichzeitigen Zugriff auf das Programm Modell.

3
Simon Richter

Ich lehne die Prämisse ab, dass eval als böser als Zeigerarithmetik oder gefährlicher als direkter Speicher- und Dateisystemzugriff angesehen wird. Ich kenne keinen vernünftigen Entwickler, der das glauben würde. Darüber hinaus unterstützen Sprachen, die Zeigerarithmetik/direkten Speicherzugriff unterstützen, normalerweise nicht eval und umgekehrt, sodass ich mir sicher bin, wie oft ein solcher Vergleich überhaupt relevant wäre.

Aber eval könnte eine bekannte Sicherheitslücke sein, aus dem einfachen Grund, dass sie von JavaScript unterstützt wird. JavaScript ist eine Sandbox-Sprache ohne direkten Speicher- oder Dateisystemzugriff. Diese Schwachstellen sind also einfach nicht vorhanden, es sei denn, es gibt Schwachstellen in der Sprachimplementierung. Eval ist daher eines der gefährlichsten Merkmale der Sprache, da es die Möglichkeit einer beliebigen Codeausführung eröffnet. Ich glaube, dass viel mehr Entwickler in JavaScript als in C/C++ entwickeln, daher ist eval für die Mehrheit der Entwickler einfach wichtiger als Pufferüberläufe.

1
JacquesB

Kein ernsthafter Programmierer würde Eval als "böse" betrachten. Es ist einfach ein Programmierwerkzeug wie jedes andere. Die Angst (wenn es eine Angst gibt) vor dieser Funktion hat nichts mit der Populärkultur zu tun. Es ist einfach ein gefährlicher Befehl, der häufig missbraucht wird und schwerwiegende Sicherheitslücken verursachen und die Leistung beeinträchtigen kann. Aus eigener Erfahrung würde ich sagen, dass es selten vorkommt, dass ein Programmierproblem auftritt, das auf andere Weise nicht sicherer und effizienter gelöst werden kann. Die Programmierer, die eval am wahrscheinlichsten verwenden, sind diejenigen, die wahrscheinlich am wenigsten dafür qualifiziert sind.

Allerdings gibt es Sprachen, in denen die Verwendung von eval angemessen ist. Perl fällt mir ein. Ich persönlich finde es jedoch sehr selten in anderen, moderneren Sprachen erforderlich, die die strukturierte Ausnahmebehandlung nativ unterstützen.

0
user1751825

Ich denke, Sie behandeln es im folgenden Teil Ihrer Frage ziemlich gut (Hervorhebung von mir):

sie haben eine gute Verwendung , solange sie ordnungsgemäß verwendet werden

Für die 95%, die es richtig benutzen könnten, ist alles gut und schön; Aber es wird immer Leute geben, die es nicht richtig benutzen. Einige davon werden auf Unerfahrenheit und mangelnde Fähigkeiten zurückzuführen sein, der Rest wird böswillig sein.

Es wird immer Leute geben, die Grenzen überschreiten und Sicherheitslücken finden wollen - manche zum Guten, manche zum Schlechten.

Was den historischen Aspekt betrifft, so ermöglichen Funktionen vom Typ eval im Wesentlichen die Ausführung von beliebigem Code , der zuvor in einem populären Web-CMS ausgenutzt wurde , Joomla! . Mit Joomla! Mit mehr als 2,5 Millionen Websites weltweit ist dies ein großer potenzieller Schaden nicht nur für Besucher dieser Websites, sondern auch für die Infrastruktur, auf der sie gehostet werden, und auch für den Ruf der Websites/Unternehmen, die ausgenutzt wurden.

Die Joomla! Das Beispiel mag einfach sein, aber es wurde aufgezeichnet.

0
gabe3886

Es gibt einige gute Gründe, von der Verwendung von eval abzuraten (obwohl einige für bestimmte Sprachen spezifisch sind).

  • Die Umgebung (lexikalisch und dynamisch), die von eval verwendet wird, ist häufig überraschend (das heißt, Sie denken, eval(something here) sollte eine Sache tun, aber eine andere, möglicherweise Ausnahmen auslösen).
  • Es gibt häufig einen besseren Weg, um dasselbe zu erreichen (die Verkettung konstruierter lexikalischer Verschlüsse ist manchmal eine bessere Lösung, aber das kann durchaus Common LISP-spezifisch sein).
  • Es ist viel zu einfach, unsichere Daten auszuwerten (obwohl dies meistens verhindert werden kann).

Ich persönlich würde nicht so weit gehen zu sagen, dass es böse ist, aber ich werde immer die Verwendung von eval in einer Codeüberprüfung in Frage stellen, mit Formulierungen entlang der Zeile "Haben Sie überlegt etwas Code) hier? " (wenn ich Zeit habe, zumindest einen vorläufigen Ersatz vorzunehmen) oder "Sind Sie sicher, dass eine Bewertung hier wirklich die beste Lösung ist?" (wenn ich nicht).

0
Vatine

In Minskys Society of Mind , Kapitel 6.4, sagt er

Es gibt eine Möglichkeit für einen Geist, sich selbst zu beobachten und trotzdem zu verfolgen, was passiert. Teilen Sie das Gehirn in zwei Teile, A und B. Verbinden Sie die Ein- und Ausgänge des A-Gehirns mit der realen Welt - damit es erkennen kann, was dort passiert. Aber verbinden Sie das B-Gehirn überhaupt nicht mit der Außenwelt. Verbinde es stattdessen so, dass das A-Gehirn die Welt des B-Gehirns ist!

Wenn ein Programm (B) ein anderes Programm (A) schreibt, fungiert es als Metaprogramm. Gegenstand von B ist Programm A.

Es gibt ein C-Programm. Das ist derjenige in Ihrem Kopf, der Programm B schreibt.

Die Gefahr besteht darin, dass es jemanden (C ') mit böser Absicht geben kann, der sich in diesen Prozess einmischen kann, sodass Sie Dinge wie SQL-Injection erhalten.

Die Herausforderung besteht darin, Software intelligenter zu machen, ohne sie auch gefährlicher zu machen.

0
Mike Dunlavey

Sie haben hier viele gute Antworten und der Hauptgrund ist eindeutig, dass willkürliche Codeausführung ist schlecht mmmkay, aber ich werde einen weiteren Faktor hinzufügen, den andere nur am Rande von berührt haben:

Es ist wirklich schwierig, Code zu beheben, der aus einer Textzeichenfolge ausgewertet wird. Ihre normalen Debugging-Tools sind so gut wie direkt aus dem Fenster und Sie sind auf das Tracing oder Echo der alten Schule reduziert. Natürlich ist das nicht so wichtig, wenn Sie ein Fragment in einem Einzeiler haben, das Sie eval möchten, aber als erfahrener Programmierer können Sie wahrscheinlich eine bessere Lösung dafür finden, wohingegen eine Codegenerierung in größerem Maßstab möglich ist irgendwo sein, wo eine Bewertungsfunktion ein potenziell nützlicher Verbündeter wird.

0
glenatron