PureBoard

Moin, ich weiss natürlich, was der PHP-Befehl eval() macht. Allerdings frage ich mich: Wozu hat man diesen Befehl überhaupt eingeführt? Das einzige sinnvolle Einsatzszenario, das ich mir vorstellen kann, ist, eine Shell zu programmieren, und das sollte ja weiß Gott nicht die Nestimmung von PHP sein...
Kennt hier vielleicht jemand ein Szenario, wo es Sinn macht, eval() zu verwenden? Würde mich echt mal interessieren...

Flexiblerer Codegestaltung.
z.B.
->
Stellt natürlich auch ein Sicherheitsrisiko dar...

Oder für meinen [php][/php] tag, damit ich in meinem CMS direkt an einer bestimmten Stelle code einfügen kann.

ich nutze diese Funktion für kurze einfach php-Tests.

Auf einer URL wird mit eine Textarea ein php-Script von mir geschreiben, dann sende ich dies ab, und lasse es dann mit Eval auusführen. Und muss damit nicht immer eine datei schreiben und hochladen ... spart n menge Zeit

Wirklich überzeugt hat mich bis jetzt eignentlich nur das mit den [php]-Tags (wobei ich das trotzdem noch relativ kritisch sehe, bei nem ordentlichen CMS sollte man doch nich noch irgendwo PHP-Code einbetten müssen).

TomS: Dein Beispiel scheint mir nicht nur recht synthetisch, sondern v.a. (wie du ja selbst zugibst) sehr unsicher zu sein.

Stargate: Dafür braucht man doch auch kein eval(), man kann den Code ja auch in ner temporären Datei speichern (braucht natürlich ein Verzeichnis mit entsprechend gesetzten Zugriffsrechten), hinter dem Code noch ein unlink("Dateiname.test"); einfügen, und das Script dann mit include("Dateiname.test"); ausführen...

//EDIT: Egal, was solls, wegen mir werden die eh kaum nen Befehl da rausschmeissen, in andern Sprachen gibts ja auch genug unsichere Befehle...

Synthetisch schon. Ist ja jeder Code. Aber prinzipiell das gleiche wie DDs PHP-Tags. Bloß, dass bei den php-tags noch normaler Text außen rum steht. Oder auch nicht...

Interessant dazu finde ich hier besonders die Warnung, was man damit
anstellen kann

http://www.php-faq.de/q-string-ausfuehren.html

Beim Woltlab Burning Board ist es z.B. so, dass sämtliche Board-Templates in der Datenbank liegen und dann per eval() ausgeführt werden.

Da ist dann auch gleich ein Editor integriert, damit man online recht simpel Änderungen an den Templates machen kann.

Ziemlich praktisch und auch sicher.

IMHO ist grade so etwas ein hohes Sicherheitsrisiko. Ich habe in den letzten Wochen mehrere Internetseiten gesehen, wo man über ne SQL-Injection Zugriff auf die Datenbank hatte. Da die normalen MySQL-User meistens keine FILE-Rechte haben, können die nicht einfach irgendein PHP-Script mit beliebigem Code auf dem Webserver speichern, ihre eigenen Tabellen können diese Benutzer aber natürlich verändern. Und genau hier liegt das Problem: Wenn jetzt ein CMS oder ein Forum irgendwo ne SQL-Injection auftaucht (und das ist in der Vergangenheit auch schon beim Woltlab-BB vorgekommen), kann der Angreifer über die DB ja beliebigen PHP-Code zur Ausführung bringen. Natürlich ist das nicht in erster Linie ein Problem von PHP sondern eins von unverantwortllichen Programmierern der jeweiligen Webanwendug, aber das Resultat ist das gleiche: Auf dem angegriffenen Server kann der Angreifer nicht nur die Datenbank auslesen, sondern auch noch eigenen PHP-Code ausführen.

Es kommt ja immer darauf an, was du anbieten willst.

Wenn du deinen Boardkäufern eine komfortable Möglichkeit bieten willst, das Board nach Herzenslust den eigenen Bedürfnissen anzupassen ist das in jedem Fall eine sichere Methode (tatsächlich im Normalfall "nur" durch Injections aushebelbar, die Löcher musst du dann natürlich versuchen zu stopfen).

Sicherer ist natürlich fixe Dateien in Ordnern ohne Schreibrechte, die die User dann eben per ftp hin- und herschieben müssen.

Aber wer Angst vor sql-injections hat, der hat sich bestimmt auch Alufolie um den Kopf gewickelt.