OT-Teil von: mysql table soll include einbinden

[h3ll]

Nun ich wollte dir nicht auf die Füsse treten.
Ich nehme an das du Probleme mit dem Einsatz der Smartyscriptsprache meinst, die Engine selbst ist ausserordentlich stabil.
Das sind keine Smartybugs das sind dann selbst fabrizierte über Templates, das muss man schon unterscheiden.
Du hast dich also mit den Fehlern anderer auseinandergesetzt, die im Zusammenhang mit Templates stehen.

Also kurz gesagt: Wenn ein Fehler auftritt, ist immer derjenige Schuld, der das Template geschrieben hat, und niemals Smarty selber. Hab ich das korrekt so zusammengefasst?

[piratos]

Also kurz gesagt: Wenn ein Fehler auftritt, ist immer derjenige Schuld, der das Template geschrieben hat, und niemals Smarty selber. Hab ich das korrekt so zusammengefasst?

Smarty selbst ist seit langer Zeit so gut wie Bug frei, die Frage kannst du dir selbst bestätigen.

[onemorenerd]

Tut mir leid, jeder der sich mal mit CMS - Entwicklung beschäftigt hat wird dir sagen, das dieses ein gediegener Unsinn ist - veraltete Ansicht.
Ob das nun direkter Code ist oder indirekter (z.B. Smarty) ist dabei völlig unerheblich.

Ich kenne dein CMS nicht. Erzähl doch mal, wie es funktioniert!
Kann der CMS-User in eine Textarea beliebigen PHP-Code schreiben, der wird dann in der DB gespeichert und beim Aufruf der Seite ge-eval't?
Junge junge, so ein Produkt würde ich niemandem empfehlen!

Was du weiter oben beschreibst, lösen andere CMS ungefähr so: Ein Modul bietet einen Block an. Der CMS-User kann den Block auf der Seite platzieren und ggf. konfigurieren. Bei der Konfiguration kann er vielleicht weitere Blöcke von anderen Modulen "einbetten". Dazu genügt aber ein Auswahldialog und ggf. weitere Konfigurationsschritte. Der CMS-User muss und darf keine einzige Zeile Code schreiben. Das ist sicher. Das ist einfach. Das ist gut.

[h3ll]

Smarty selbst ist seit langer Zeit so gut wie Bug frei, die Frage kannst du dir selbst bestätigen.

Komisch, dass ich dann immer wieder neuen Bugs über den Weg laufe.

[piratos]

Ich kenne dein CMS nicht.

Tja du wisst ja wo man downloaden kann.

Vielleicht hast du auch schon mal was von Rechten gehört und dem Unterschied zwischen ein CMS und einem Portalsystem.
Ich schreibe keine Portalsysteme als Opensource.

[onemorenerd]

Ich will dein CMS aber nicht erst runterladen, installieren und durchklicken müssen.
Warum bist du nicht bereit, kurz zu beschreiben wie und warum du in deinem CMS eval() einsetzt? Soviel Gesprächsbereitschaft muss schon sein.

[onemorenerd]

Habs inzwischen mal runtergeladen und nach eval() gesucht. Erster Fundort /lib/classes/class.usertagoperations.inc.php:54

if (!(@eval('function '.$functionname.'(&$params, &$smarty) {'.$code.'}') === FALSE)) 
    $result = call_user_func_array($functionname, array(&$params, &$smarty)); 

Ein weiterer Treffer in verwaltung/adduserplugin.php:81

@ob_start();
            if (eval('function testfunction'.rand().'() {'.$code.'}') === FALSE)
            {
                $error[] = lang('invalidcode');
                                $buffer = ob_get_clean();
                                $error[] = preg_replace('/<br \/>/', '', $buffer );
                $validinfo = false;
            }
            else
                ob_end_clean(); 

Du verwendest eval() hier beide Male um zu prüfen, ob der Code, der offensichtlich vom CMS-User eingegeben wurde, valider PHP-Code ist. Liege ich damit richtig?
Was passiert, wenn der CMS-User "} unlink(__FILE__); {}" eingibt?

[PHP-Desaster]

eval in Templates ist ja eine Sache, um sehr einfach irgendwelche foreachs, etc. in HTML einzubetten, hat so aber nichts mit Smarty zu tun, weil dieses im Endeffekt nur wieder PHP erzeugt und per include + ob rendert.
Deine function-Konstrukte sehen dagegen sehr abenteuerlich aus. Schon mal php -l auf der CLI verwendet? In Kombination mit einer temporären Datei oder Shell-Pipes eine klasse und saubere Sache.

[onemorenerd]

Und von den zahlosen Templateengines die ohne eval das machen können hätte ich gerne noch weitere Referenzen.

Gerade ist mir was über den Weg gelaufen: Templating Engines in PHP - Fabien Potencier Dieses Twig kommt ebenfalls ohne eval() aus.

Das ist übrigens die erste Template Engine, die ich kenne, die sich für DSLs eignet. Denn man kann die Template-Sprache nicht nur erweitern, sondern auch bestehende Tags überschreiben und sogar den AST manipulieren. Das sind Features, die PHP als Template Engine nicht bietet und damit hat Twig eine echte Daseinsberechtigung.

[fireweasel]

Habs inzwischen mal runtergeladen und nach eval() gesucht. Erster Fundort /lib/classes/class.usertagoperations.inc.php:54 ... Du verwendest eval() hier beide Male um zu prüfen, ob der Code, der offensichtlich vom CMS-User eingegeben wurde, valider PHP-Code ist. Liege ich damit richtig?
Was passiert, wenn der CMS-User "} unlink(__FILE__); {}" eingibt?

http://de.php.net/manual/en/function...eck-syntax.php

Da gibts eine Riesenmenge von Userkommentaren, die das PHP-Syntax-Checking-per-Eval()-Problem in den Griff zu bekommen versuchen. Da werden geschweifte Klammern gezählt und halbe PHP-Quellcode-Parser gebaut. Einige Ansätze funktionieren sogar. ;-)

Die Funktion selbst war leider nur kurze Zeit offizieller Bestandteil von PHP.

[recoil]

Danke Piratos fuer deine Vorlage, ich habe es jetzt hinbekommen.
Ich habe es fuer meine Website so in der index.php verwendet

<?php include($item['include']);?>

[ragtek]

Ich kenne dein CMS nicht. Erzähl doch mal, wie es funktioniert!
Kann der CMS-User in eine Textarea beliebigen PHP-Code schreiben, der wird dann in der DB gespeichert und beim Aufruf der Seite ge-eval't?
Junge junge, so ein Produkt würde ich niemandem empfehlen!

Das vB macht es zB so

Aber ja,
Ich würde den Code einmal aus der DB lesen und in eine Datei schreiben(cachen).
Das erspart doch die DB Abfrage.

[onemorenerd]

Das vB macht es zB so

Wußte ich gar nicht, habe vB aber auch noch nie verwendet oder weiterempfohlen. Werde ich auch nicht.

@fireweasel: Syntaxprüfung ist (wäre?) zwar nett, schützt aber nicht vor semantisch "böswilligem" Code. Das geht nur durch kontrolliertes Ausführen in einer Sandbox (z.B. VM). Im Webumfeld völlig abwegig.

[fireweasel]

Wußte ich gar nicht, habe vB aber auch noch nie verwendet oder weiterempfohlen. Werde ich auch nicht.

Parse error: syntax error, unexpected T_STRING in /home/medkaau/public_html/vb/index.php(565) : eval()'d code on line 2

Und dieser Angriff wurde nur entdeckt, weil auch der "pöse Hacker" seinen Quellcode vor dem Upload nicht auf Syntax-Fehler gecheckt hat.

@fireweasel: Syntaxprüfung ist (wäre?) zwar nett, schützt aber nicht vor semantisch "böswilligem" Code. Das geht nur durch kontrolliertes Ausführen in einer Sandbox (z.B. VM). Im Webumfeld völlig abwegig.

Wenn ich mich recht erinnere (das ist schon ein Weilchen her), bin ich davon ausgegangen, dass der PHP-Quellcode von einem Menschen eingegeben wird, der dem Webmaster wohlgesonnen ist, also ein Kollege, Mitarbeiter oder der Site-Betreiber selbst. Eingaben anderer Benutzer ist selbstverständlich grundsätzlich Böswilligkeit zu unterstellen. Hab mir den Quellcode des diskutierten CMS aber nicht näher angeschaut.

Ich bin zwar kein notorischer eval()-Gegner, aber wer diese Funktion anwendet, sollte ganz genau wissen, was er oder sie tut. Die meisten wissen das offensichtlich nicht.

[ragtek]

Nur um auf Pluginsysteme zurückzukommen.

Im Endeffekt ist es doch egal, ob ein System eval oder etwas anderes benutzt, das eigentliche Problem liegt wie immer beim Benutzer.

Es ist doch egal ob man ein System durch Dateiänderungen laut Anweisung, eval oder require_once verändert.
Über jede von den genannten Möglichkeiten kann böser Code eingeschleust werden